我问的是pattern，而不是framework。这是关于UI auto-generation的问题的后续行动。
您是否相信元数据中UI自动生成的概念？
可以通过这种方式解决哪些问题？
当我创建small library来支持我的学生项目时会出现问题，该项目基于对象的元数据在运行时生成交互式CLI。我认为它产生的CLI非常不错。
另一个极端是Naked Objects Framework，这是相当普遍的，但它生成的UI很可怕，IMO。
很明显，每个问题都是具体的，需要特定的用户界面，但也许有几类问题可以接受自动生成？
答案 0 :(得分：15)
是的，我相信基于元数据的自动生成应用程序的概念非常合理 - 主要是因为它大大减少了开发时间并通过减少大多数应用程序中的大量冗余来提高代码质量，其中每个域数据字段都表示在数据库，模型中，UI中，以及在各种映射层中也经常多次。
我认为未来是自动生成的应用，可以在必要时进行修改。目前，这是AFAIK真的不可能;例如，Rails只允许您在使用静态脚手架时完全自定义UI，这基本上意味着代码生成，即域模型中的许多进一步更改不会自动在UI中表示，因为生成代码时发生了重复
我认为第一个将完整的自动生成与完全可修改性结合起来的框架将成为事实上未知程度的事实上的开发标准。虽然我们很可能会以小步骤实现这一目标，但不会有这样一个统治框架。
答案 1 :(得分：6)
看看JMatter，这是一个相当好看的Naked Objects实现。
还有Chris Muller关于MAUI的工作，以及Lukas Renggli关于Magritte（Squeak / Smalltalk）的工作
我们在应用程序的配置部分中有很多生成的UI。这些列表永远存在，并由系统管理员在蓝色的月亮中改变一次。
我发现大多数具有数据库后端的应用程序往往从OO和NO角度来看设计不好，如Pawson和Matthews的NO书中所示。
答案 2 :(得分：4)
Re：qn＃1 ...您是否相信元数据中UI自动生成的概念？ ...我肯定会对你的第一个问题回答'是'，作为Naked Objects（Java）框架的提交者之一，写一本关于DDD + NO的书。
问题提及元数据。我认为这是否能够取得成功的关键。在最新版本（将在2月份进行测试）中，元模型已经打开，因此它非常易于扩展，因此您可以按照自己的编程约定/注释编写域模型，或者可能使更复杂的查看器可以查找自己的元数据以提供更复杂的视图。 （例如，考虑如果一个对象实现了一个位置界面，那么它将显示在谷歌地图中）。
关于qn＃2 ...这种方式可以解决什么样的问题...我们总是说NO更适合“主权应用程序”（在组织内部使用的事务性，操作系统） “瞬态应用”（比如机场售货亭）。 NO GUI确实要求用户熟悉域，否则他们将不知道他们在看什么。
当然，缺少的仍然是复杂的观众。你是对的NO GUI，它绝对是低保真度（虽然.NET版本是一个很大的改进，请参阅最近的infoq.com文章）。在Java方面有一个名为scimpi.org的姐妹项目虽然有很多承诺......但它提供了免费的基本Web GUI，但允许您根据需要和增量手工制作网页。我也正在开发一个类似的Eclipse RCP GUI。
另外要添加的是，即使您选择编写自定义GUI和/或表示层，NO方法也具有价值（我相信）。也就是说，您可以将它用作构建非常实体的pojo域图层的设计工具，然后将其设置为皮肤。麻烦的是，NO从来没有以这些方式出售，因此大多数人都认为NO模式是一种全有或全无的事情。
丹
答案 3 :(得分：3)
考虑这一点的一种方法是考虑从Toad或MySQL Browser获得的用户界面之间的区别，其中用户界面直接从表及其关联的元数据构建，以及用户界面熟练的设计师将为实际应用开发。如果没有太多不同，那么自动生成框架应该是相当低的成果。
正如你所说，有一类问题可以很好地适用于这种自动生成，有些则不会。在我看来，关键的事情是你在用户界面中公开的实现模型（或其部分）与用户的概念模型的映射程度。其次，通过一组有限的用户界面组件可以表达应用程序的行为（假设这是一个通用的UI生成框架）。
这篇文章“Universal Model of a User Interface”可能会引起关注。
答案 4 :(得分：2)
我认为自动生成的UI的想法有很多潜力，特别是对于普通的表格和表格布局数据库用户界面。然而，即使人类需要在循环中，也能够覆盖输出而不会被下一次重生覆盖。
如果交互设计人员更多地参与开发生成算法，我怀疑自动生成的UI今天会更成功。我的印象是，从历史上看，这些系统的创建者不知道要包含哪些与UI相关的元数据或如何使用它。指定字段的标签，值范围，格式和顺序是一个开始，但需要更高级别的信息。特别是对任务和用户角色的充分建模往往缺乏，以及UI的一些基本的样式指南级原则。
例如，Oracle的Designer 2000在正确的轨道上不仅包括模型中的实体和关系，还包括功能层次结构形式的任务。然后，他们通过误用这个元数据（例如，假设深度总是优于宽度）并且在生成UI时包括基本缺陷（例如，一次只能打开一个主窗口）来吹掉它。结果是IU甚至与Oracle自己的应用程序用户界面标准不一致。答案 5 :(得分：2)
快速获取基本用户界面快速，让客户试用系统，创建测试数据必须具有价值。 Naked Objects框架可以帮助“引导捆扎”，即使您必须在发货之前用“手工制作”UI替换它。
在我参与的大多数系统中，有很多简单的管家表。所有这些表都需要一个UI来编辑和查看它们等。这些简单的编辑器具有很大的价值。在这里，裸体对象框架可以节省大量时间，即使主要的“日常”UI是“手工制作”
答案 6 :(得分：2)
我已经看到了一些失败的项目（我作为一个相当昂贵的顾问来帮助设计替换的情况），它使用了“裸体对象”方法（不是框架，AFAIK） - 所有这些都只是简单的恶意用户界面并且在一个项目中替换了很多UI，在其原始版本中，它采用了类似的方法（整个应用程序是通过上下文菜单和属性表访问的对象树 - 这是NetBeans 2.0大约1998年 - IDE作为巨型分层JavaBean）。
最重要的是，您的用户并不关心您的架构，他们关心的是在您可以提出的最易理解的一组互动中获得他们需要做的事情。如果这恰好与您的建筑保持一致，那么您将度过一个幸运的日子 - 但这确实是偶然的。试图强制用户关心（甚至了解）您的架构是一个没有人想要使用的软件的配方。
代码通常需要围绕两个并不总是兼容的目标设计：
为满足这两个目标而创建的抽象和代码结构非常非常非常少地映射到任何类型的用户界面元素。如果你的观众是技术人员，有时你可以侥幸逃脱。但即使在那里，你可能会为更多用户提供至少一个“表示层”适配器层，而这个适配器层位于对程序员和机器有意义的架构之上。