为什么不基于数据库模式构建UI？

Question

人们似乎避免构建从数据库中提取信息（名称，字段类型等以及关系）的用户界面;相反，它们硬编码具有几乎相同的数据名称和类型和事物的表单（和表格等）。

我有道理吗？

例如，想象一下MySQL中的一个数字字段：为什么不在每次遇到ENUM时都让UI构建一个下拉列表？为什么在数据库和代码中都放置相同的值？

也许我只是遗漏了一些东西;也许有些项目可以做到这一点 - 可以指向任何数据库的超级crud接口，并从中构建一个功能齐全的关系感知用户界面。有吗？

我可能不太符合这个问题的stackoverflow规范;我将总结一下：

1. 您能告诉我一个项目，它（仅）通过分析数据库架构来构建其用户界面吗？
2. 为什么这不是一种常用的方法 - 当然只在一个地方（即数据库）定义数据结构是好的？

谢谢你，并且可能会喜欢在你的IDE上爱上雨。

Answer 1

我想指出的是，上次我检查时，.NET和Qt（可能还有其他环境）可以使用“数据库感知小部件”（有时简称为数据感知小部件），可能是最好的实用解决方案。数据感知小部件的意思是小部件本身知道它们直接链接到数据库字段，因此您将拥有一个组合框，它知道它由枚举支持并在运行时直接从数据库中获取可能的值，就像你建议的那样。

这是一个非常简洁的实用程序，使用得很好，它可能不会伤害任何东西。它仍然需要您花一些时间在表单上手动布置窗口小部件，但是如果您更新数据库以向该枚举添加新值，则不必重新构建应用程序以使其显示在UI中。

但大多数可用性专家在听到您的问题时会畏缩的原因是程序员倾向于认为，为什么不从数据库生成整个 UI，表单布局和所有内容？这就是它开始变得非常讨厌，非常快的地方。

假设你有一个简单的Person表，包括first_name，last_name，email_address，street_address，city，state，zip和phone_number。您希望根据这些字段自动生成UI。你如何对田地进行排序？我的意思是，理想情况下，名字和姓氏应该紧挨着。如果你在街道地址之前有城市和州，那就太傻了。因此，您必须向表中添加新列以指定排序顺序（如果您使用最快的方法）或新表来指定每个字段的字段ID的订单索引。

如果您想单独分组部分信息怎么办？然后，您必须在数据库布局中添加更多特定于UI的cruft（为了做到这一点，您需要一个新表来指定哪些UI字段属于哪些UI组框）。所以你只解决了两个问题并且你的数据库布局已经变得丑陋了两倍，加上现在加上UI后你不必进行简单的O（1）布局操作，你必须做几个数据库查询来找出哪些字段存在并在应用正确的小部件顺序时动态布局它们...我们甚至没有处理大小调整（每个字段应该是最大尺寸以适应其可能的内容，还是所有文本字段都应该是相同的宽度？不会'如果你可以说一些文本字段应该是一个宽度和高度，而另一些应该是另一种组合？等），或者文本对齐，或格式化，或任何其他真正常见的基本可用性要求，需要进一步牺牲，这是很好的数据库架构的清晰度和简洁性。

Answer 2

1. 大多数可视化数据库编辑器。例如phpMyAdmin。

2. 因为数据库结构对于用户来说并不总是一个非常好的逻辑结构，特别是在出于效率原因而故意非规范化的数据库的情况下。

Answer 3

是的，这条路线已经走过了。

简单地指向数据库将创建一个过度简化的UI，而不是提供远远超过Access UI的CRUD。这就是Naked Objects（我是其提交者之一）从pojo域模型构建其元模型的原因。这允许UI将任何公共方法公开为菜单...我们称之为“行为完整”。

根据关于UI不适合最终用户的评论，我有两点：

1. 区分高级用户与临时用户。大多数内部应用程序都是针对前者的（我们使用Alan Coopers的“主权应用程序”这个术语），他们了解域名并且不希望花哨的UI东西妨碍。大多数外部应用程序，例如公共网站，都是针对后者的。

2. 对于后者，没有什么可以阻止像Naked Objects这样的工具的自动生成UI被自定义或半自定义查看器替换。一个这样的观察者是Scimpi，我也在研究Eclipse RCP查看器，它将公开扩展点。但即使在这里，auto gen UI对于开发团队和业务分析师来说仍然非常有价值，可用于探索和原型设计。

希望上面的一些内容激起了你的兴趣。如果你想要更多，谷歌，或者你可能想看看我的关于域驱动设计的书和NO，请访问pragprag.com。

HTH 丹

Answer 4

实施这一想法的项目清单。

<强> .NET

• dotObjects
• Naked Objects
• TrueView

<强>爪哇

• Domain Object Explorer
• JMatter
• Naked Objects
• Sanssouci
• Trails
• Lablz

<强> C ++

• Typical Objects

Answer 5

具体到你的第二个问题：很多都取决于你的数据模型。有些非常复杂，会导致用户界面不直观。也许对于简单的基于CRUD的系统，将UI作为数据库的前端是更可取的。在这种情况下，我认为其中一些工具会很棒。但是，对于某些需要向用户隐藏某些数据库数据的更复杂的系统，如果UI没有镜像数据库模式，那就更好了。

Answer 6

Microsoft Access多年来一直使用此模型 - 数据库和UI开发紧密相关。您可以直接从具有智能默认值和内置搜索的表定义自动生成表单。该模型适用于开发具有少量并发用户的应用程序，例如用于存储数据量较小的小型企业的自定义应用程序。

如果要扩展到具有大量并发用户或大型数据库的较大关系数据库，则可靠性和性能变得更加重要，并且单独构建的UI和数据库更有意义。当涉及更多用户时，他们通常会有不同的要求，因此将UI与数据库模式分离可以使开发更有效。

Answer 7

关于Java“实现这一想法的项目”的说明“ - tynamo是Trails框架的新版本

Answer 8

有许多系统可以构建一个界面，供您直接从表信息中编辑内容。但是，最终用户界面必须稍微调整一下。您可能不希望向用户显示表格中的每个字段。

充分利用MVC设计模式的框架可以让您使用模型执行各种操作，这是构建新系统的首选方式（而不是直接创建数据库表）。

具体回答您的问题：

1. django允许您从模型中构建表单（以及完整的管理CMS）。

2. 是常见的事情。

Answer 9

Naked Objects与此相关只有一步之遥。它们将UI基于对象模型，然后保留对象模型。

Answer 10

如果您这样想，我认为您在设计过程中忘记考虑用户。错误。当界面发生变化时，用户不喜欢它，如果频繁更改，他们会特别不喜欢它，因为他们不知道该怎么做。此外，如果您根据数据库结构动态生成UI，那么对象的顺序是什么？ UI需要按照对用户而不是数据库设计者有意义的顺序来拥有对象。

此外，在精心设计的数据库中，有些字段不是供用户查看的。数字键，插入日期，最后更新等等。您不希望自动向用户公开这些内容，您当然不希望他们能够在这些字段中混淆数据。

最后，如果你没有考虑页面的功能，那么你就没有做好自己的工作。 UI需要的不仅仅是可以编辑的文件列表。您需要限制谁可以在插入数据库之前查看数据，检查数据，以及需要应用的业务规则。你不能只是自动生成很多这个（你甚至不应该！）。设计需要思考和关怀。

现在，为了下拉列表，当然你可以从数据库而不是代码生成它们，实际上它是更好的选择。只需将查询作为特定对象的源，而不是代码中生成的列表。

Answer 11

你可以借助菲律宾开发人员提供的这个很酷的工具来实现它，它被称为COBALT。您可以下载here。