从数据库生成UI - 好的，坏的和丑的？

Question

我已经阅读了一个声明，从DB布局（或业务对象，或任何其他业务层）自动生成UI是一个坏主意。我还可以想象一下，为了制造这样的东西，我们必须面对一些好的挑战。

然而，我没有看到（也找不到）任何尝试它的人的例子。因此，我想知道 - 它真的那么糟糕吗？这绝对不容易，但可以通过任何措施成功完成吗？主要障碍是什么？看到一些成功和失败的例子会很棒。

澄清 - 使用“自动生成UI”我的意思是所有形式及其所有控件都是完全自动生成的（在运行时或编译时），可能基于元数据中有关如何表示数据的一些提示。这与手工设计形式形成鲜明对比（正如大多数人所做的那样）。

已添加：找到this somewhat related question

已添加2：好吧，如果有足够的与演示相关的元数据可用，这似乎可以获得相当公平的结果。对于这种方法，多少是“足够的”，并且比手动设计表单更少的工作？它是否也为未来的变化提供了更大的灵活性？

Answer 1

我们有一个项目可以生成数据库表/存储过程以及业务类的UI。它是在.NET中完成的，我们在类和属性上使用了大量的自定义属性，使它能够按照我们想要的方式运行。它工作得很好，如果你设法遵循你的设计，你可以很容易地创建你的软件自定义。我们也确实有一种方法可以为一些特殊情况添加“自定义”用户控件。

总而言之，它对我们来说效果很好。不幸的是，它是一种销售的银行产品，并且没有可用的来源。

Answer 2

对于所有你需要的东西来说，只需要一种实用的方法来获取数据就可以了。

对于任何类似真实应用的东西，这是一个糟糕的主意。良好的用户界面是人性化的因素，你调整的位数可以确保这台机器能够很好地响应人的触摸。

当你的界面是机械生成的时候，你无法得到它......好吧也许是接近AI的东西。 ：）

编辑 - 澄清：从代码/ db生成的UI作为一个起点很好，它只是一个垃圾终点。

Answer 3

嘿，这根本不难实现，而且根本不是一个坏主意。这一切都取决于您的项目需求。很多软件产品（介意你不是项目而是产品）依赖于这个模型 - 因此他们不必为不同的客户需求重写他们的代码/ ui逻辑。客户可以按照他们在管理系统中使用设计器表单的方式自定义他们的用户

我使用xml来保存这类东西的元数据。我为每个领域保存的一些属性是：

1. friendlyname（标签标题）
2. haspredefinedvalues（是的，用于删除 下拉列表/多重复选框列表）
3. multiselect（如果是，则复选框 列表，如果没有，则下拉列表）
4. 数据类型
5. 的maxlength
6. 需要
7. MINVALUE
8. MAXVALUE
9. 正则表达式
10. 已启用（显示或不显示）
11. sortkey（网络表单上的订单）

关于定位 - 我并不在意，只是简单地在另一个下面生成table tr td标签 - 但是如果你想要实现它，你可以再增加一个名为CssClass的属性，你可以在其中定义ui特定的属性（看起来和感觉，定位等）这里

更新：还要注意当你想要输入产品信息时，许多电子商务产品都遵循这种动态ui - 因为他们的客户可以在阳光下销售从家具到性玩具的所有东西;-)所以不要重写他们的代码对于每个不同的行业，他们只需让客户通过管理表单输入产品属性的元数据： - ）

我还建议你看看Entity-attribute-value model - 它有自己的优点和缺点，但我觉得它可以很好地满足你的要求。

Answer 4

在我的意见中你应该考虑一些事情：

1. 客户是否需要一个功能来自定义他的UI？
2. 是否有很多不同的属性或元素？
3. 创建这样一个“渲染引擎”的努力值得吗？

好吧，我认为你应该考虑这些问题非常明显。如果那种模型有意义，那真的取决于你的项目...... 如果你想创建一些可以在运行时自定义的表单，那么这个模型可能非常有用。此外，如果你需要做很多较小的工具，并将它用作某种“引擎”，那么这项工作可能是值得的，因为你可以节省大量的时间。 使用这种“渲染引擎”，您可以自动添加错误报告，检查值或添加始终使用相同模式构建的其他内容。但是如果你有太多的东西，元素或属性，那么性能可能会迅速下降。 在更大的项目中变得有趣的另一件事是，必须在引擎中进行必须在每个表单中进行的更改，而不是在每种形式中。如果完成的应用程序中存在错误，这可以节省很多时间。

在我们公司，我们使用类似的模型为现金软件之间的接口生成器（现在我不记得正确的单词...）和我们的应用程序，只是它没有创建UI，但输出文件其中一个应用程序。 我们使用XML来定义结构以及如何转换值等等。

Answer 5

我想说在大多数情况下，数据不适合UI生成。这就是为什么你几乎总是在它们之间放置一层逻辑来向用户解释数据库信息。另一件事是，当您从DB生成UI时，您将最终显示系统的内部工作方式，这是您通常不想做的事情。

但这取决于数据库的来源。如果它是为了准确反映系统的用户目标而创建的。如果应用程序应该帮助他们的用户心理模型存储在DB中。然后它可能会工作。但是你有从用户端开始。如果不是，我建议你不要这样做。

Answer 6

您能从应用程序架构的角度看问题吗？我认为你是另一个数据库恐怖分子 - 试图通过编写存储过程解决所有问题。为什么要使用UI？尝试在DB脚本中执行此操作。在这种方法的效果 - 你最终会在什么复合系统？当系统服务于不同的业务时 - 尝试模块化，有选择地发现组件，限制共享引用。 UI应是可替换的，独立于业务层。当在DB中存储如此多的数据时 - UI的硬依赖性 - 系统变成了整体。在生成UI时如何在场景中实现MVVM模式？像Blend这样的设计师包含许多功能，这些功能无法被大多数未来的UI生成器取代 - 除非 - 您的开发平台仅限于记事本。

Answer 7

存在一种混合方法，其中在数据库中描述表单和所有表单以确保服务器端的一致性，然后对其进行编译以确保客户端在部署时的效率。

一个真实的例子是企业软件MS Dynamics AX。

它有一个“数据” 数据库和一个“模型” 数据库。

“模型” 存储表单，类，作业以及应用程序需要运行的每个工件。

部署用于转储模型数据库并启动CIL编译（通用中间语言的CIL，Microsoft在.net中使用的东西）的新软件结构

这种方式适用于企业范围的软件，并且可以处理大型定制。但是请记住，这种方法设置的框架应该为以后将要维护和定制应用程序的人所理解。

Answer 8

我这样做（在 PHP/MySQL 中）是为了自动生成我为客户端构建的 CMS 的部分。它工作正常，我的主要问题是生成表单的代码变得非常不透明且难以理解，因此难以重用和修改，所以我没有重用它。

请注意，表遵循严格的约定，例如命名等，这使得 UI 可以预期特定列并推断有关列和表命名的信息。需要元信息来帮助 UI 显示数据。

通常它可以工作，但问题是如果您的 UI 只是镜像数据库，那么可能还有很大的改进空间。一个好的 UI 应该做的不仅仅是镜像数据库，它还应该围绕人类交互模式和偏好构建，而不是围绕数据库结构。

因此，基本上，如果您想要便宜并制作一个快速而肮脏的界面来反映您的数据库，那么就去做吧。主要的挑战是找到可以做到这一点或自己编写的高质量代码。