我在某处读过一个声明，即从 DB 布局（或业务对象，或任何其他业务层）自动生成 UI 是一个坏主意。我还可以想象一个人必须面对一些好的挑战才能做出这样的事情。
但是，我没有看到（也找不到）任何尝试它的人的例子。因此，我想知道 - 真的那么糟糕吗？这绝对不容易，但任何措施都可以成功吗？主要障碍是什么？很高兴看到一些成功和失败的例子。
澄清一下 - “自动生成 UI”我的意思是所有表单及其所有控件都是完全自动生成的（在运行时或编译时），可能基于元数据中关于如何表示数据的一些提示。这与手工设计表单（就像大多数人所做的那样）形成对比。
补充：发现这个有点相关的问题
补充 2：好的，似乎可以获得相当公平结果的一种方法是，如果有足够的与演示相关的元数据可用。对于这种方法，多少是“足够”的，它会比手动设计表单少吗？它是否也为未来的变化提供了更大的灵活性？
我们有一个项目，它将生成数据库表/存储过程以及来自业务类的 UI。它是在 .NET 中完成的，我们在类和属性上使用了很多自定义属性，以使其按照我们想要的方式运行。虽然它工作得很好，如果你设法遵循你的设计，你可以很容易地创建你的软件的定制。我们也确实有办法为一些非常特殊的情况添加“自定义”用户控件。
总而言之，这对我们来说效果很好。不幸的是，它是一种出售的银行产品，没有可用的来源。
对于一些微小的东西来说没关系，你只需要一种实用的方法来获取数据。
但是，对于任何类似于真实应用程序的东西，这是一个糟糕的主意。一个好的 UI 是人性化因素，你可以调整的部分，以确保这台机器对人的触摸反应良好。
当您的界面是机械生成的时，您就无法做到这一点......也许是接近人工智能的东西。:)
编辑 - 澄清：从 code/db 生成的 UI 作为起点很好，它只是一个垃圾终点。
嘿，这根本不难实现，这也不是一个坏主意。这一切都取决于您的项目需求。许多软件产品（请注意不是项目而是产品）依赖于这个模型——所以他们不必为不同的客户需求重写他们的代码/用户界面逻辑。客户可以使用管理系统中的设计器表单以他们想要的方式自定义他们的用户界面
我已经使用 xml 来保存这类东西的元数据。我为每个字段保存的一些属性是：
关于定位 - 我不太在意，只是在另一个下方生成表 tr td 标签 1 - 但是，如果您也想实现这一点，您可以再拥有 1 个名为 CssClass 的属性，您可以在其中定义 ui 特定属性（外观和感觉，定位等）在这里
更新：还请注意，当您想要输入产品信息时，许多电子商务产品都遵循这种动态用户界面 - 因为他们的客户可以在阳光下销售从家具到性玩具的所有东西 ;-) 所以而不是为每个不同的东西重写他们的代码行业他们只是让他们的客户通过管理表单输入产品属性的元数据:-)
我还建议您查看Entity-attribute-value 模型- 它有自己的优点和缺点，但我觉得它可以很好地满足您的要求。
在我看来，您应该考虑以下几点：
好的，我认为这很明显为什么你应该考虑这些。这种模型是否有意义真的取决于你的项目......如果你想创建一些可以在运行时自定义的表单，那么这个模型可能非常有用。此外，如果您需要做很多较小的工具并将其用作某种“引擎”，那么这种努力可能是值得的，因为您可以节省大量时间。使用这种“渲染引擎”，您可以自动添加错误报告、检查值或添加始终以相同模式构建的其他内容。但是如果你有太多这样的东西、元素或属性，那么性能就会迅速下降。在更大的项目中变得有趣的另一件事是，必须在每种形式中发生的更改只需要在引擎中进行，不是每种形式。如果完成的应用程序中存在错误，这可以节省大量时间。
在我们公司，我们在现金软件（现在我不记得正确的词......）和我们的应用程序之间使用类似的模型作为接口生成器，只是它不创建 UI，而是为其中一个创建一个输出文件应用程序。我们使用 XML 来定义结构以及需要如何转换值等等。
我会说，在大多数情况下，数据不适合 UI 生成。这就是为什么您几乎总是在两者之间放置一层逻辑来向用户解释数据库信息。另一件事是，当您从 DB 生成 UI 时，您最终会显示系统的内部运作，这是您通常不想做的事情。
但这取决于数据库的来源。如果创建它以准确反映系统的用户目标是什么。如果应用程序应该帮助他们的用户心理模型存储在数据库中。那么它可能只是工作。但是你必须从用户端开始。如果不是，我建议你不要那样做。
你能从应用程序架构的角度来看待你的问题吗？我认为你是另一个数据库恐怖分子——试图通过编写存储过程来解决所有问题。为什么要有 UI？尝试在数据库脚本中执行此操作。这种方法的效果——你最终会在什么复合系统上？当系统服务于不同的业务时——尝试模块化、选择性地发现组件、限制共享引用。UI 应该是可替换的，独立于业务层。当在 DB 中存储如此多的数据时——UI 存在硬依赖——系统变成了单体。生成 UI 时如何在场景中实现 MVVM 模式？像 Blend 这样的设计师包含许多功能，大多数未来派的 UI 生成器都无法替代 - 除非 - 您的开发平台仅是记事本。
有一种混合方法，其中表单和所有内容都在数据库中进行描述，以确保服务器端的一致性，然后对其进行编译以确保客户端在部署时的效率。
一个真实的例子是企业软件 MS Dynamics AX。
它有一个“数据”数据库和一个“模型”数据库。
“模型”存储应用程序需要运行的表单、类、作业和每个人工制品。
部署新的软件结构曾经是转储模型数据库并启动CIL编译（CIL为通用中间语言，微软在.net中使用的东西）
这种方式适用于企业范围的软件，并且可以处理大型定制。但请记住，这种方法设置了一个框架，以后维护和自定义应用程序的人都应该很好地理解该框架。
我这样做（在 PHP / MySQL 中）是为了自动生成我为客户端构建的 CMS 的部分。它工作正常，我的主要问题是生成表单的代码变得非常不透明且难以理解，因此难以重用和修改，所以我没有重用它。
请注意，表遵循严格的约定，例如命名等，这使得 UI 可以预期特定列并推断有关列和表命名的信息。需要元信息来帮助 UI 显示数据。
一般来说它可以工作，但问题是如果你的 UI 只是镜像数据库，那么可能还有很多改进的空间。一个好的 UI 应该做的不仅仅是镜像数据库，它应该围绕人类交互模式和偏好构建，而不是围绕数据库结构。
因此，基本上，如果您想便宜并做一个快速而肮脏的界面来反映您的数据库，那么就去做吧。主要的挑战是找到可以做到这一点的高质量代码或自己编写。