15

我问的是模式，而不是框架。这是关于UI 自动生成的问题的一种后续。

  1. 你相信从元数据自动生成 UI 的概念吗？

  2. 这种方式可以解决什么样的问题？

当我创建了一个小型库来支持我的学生项目时，问题就出现了，它根据对象的元数据在运行时生成交互式 CLI。而且我认为它生成的 CLI 相当不错。

另一个极端是Naked Objects Framework，它相当通用，但它生成的 UI 很糟糕，IMO。

很明显，每个问题都是特定的并且需要特定的 UI，但也许有几类问题可以接受自动生成？

4

7 回答 7

15

是的，我相信基于元数据的自动生成应用程序的概念非常合理——主要是因为它通过减少在数据库中表示每个域数据字段的大多数应用程序中的大量冗余，大大减少了开发时间并提高了代码质量，在模型中，在 UI 中，并且经常在各种映射层中多次。

我认为未来是自动生成的应用程序，可以在必要时进行修改。目前，这是 AFAIK 不太可能；例如，Rails 仅允许您在使用静态脚手架时完全自定义 UI，这基本上意味着代码生成，即领域模型中的许多进一步更改不会自动在 UI 中表示，因为在生成代码时发生了重复.

我相信第一个能够将完全自动生成与之后的完全可修改性结合起来的框架将成为事实上的开发标准，达到以前未知的程度。虽然我们很可能会以小步骤到达那里，这样就不会有这样一个单一的主导框架。

于 2009-01-18T11:14:04.960 回答
6

看一下 JMatter，它是一个更好看的 Naked Objects 实现。

http://www.jmatter.org

还有 Chris Muller 在 MAUI 上的工作，以及 Lukas Renggli 在 Magritte 上的工作（都是 Squeak /Smalltalk）

我们在应用程序的配置部分有很多生成的 UI。所有那些永远存在并被系统管理员更改一次的列表。

我发现从 OO 和 NO 的角度来看，大多数具有数据库后端的应用程序的设计往往很糟糕，正如 Pawson 和 Matthews 的 NO 一书所示。

于 2009-01-18T11:52:17.690 回答
4

Re: qn #1 ... 你相信从元数据自动生成 UI 的概念吗？...我肯定会对你的第一个问题回答“是”，作为裸对象 (Java) 框架的提交者之一，并写一本关于 DDD + NO 的书。

问题提到了元数据。我认为这是 NO 能够成功的关键。在最新版本（将在 2 月进行测试版）中，元模型已经开放，因此它非常可扩展，这样您就可以按照自己的编程约定/注释编写域模型，或者可能让更复杂的查看器可以寻找自己的元数据以提供更复杂的视图。（例如，考虑如果一个对象实现了一个 Location 接口，那么它就会显示在谷歌地图中）。

关于 qn #2 ...可以通过这种方式解决什么样的问题...我们一直说 NO 更适合“主权应用程序”（组织内部使用的事务性、操作系统）到“瞬态应用程序” ”（比如机场信息亭）。NO GUI 确实要求用户熟悉域，否则他们将不知道他们在看什么。

当然，还缺少成熟的观众。你对 NO GUI 的看法是对的，它绝对是低保真度（尽管 .NET 版本是一个很大的改进，请参阅最近的 infoq.com 文章）。在 Java 方面，有一个名为 simpi.org 的姊妹项目，尽管它有很多希望......它免费提供基本的 Web GUI，但允许您根据需要和增量手工制作网页。我也在开发一个类似的 Eclipse RCP GUI。

不过要补充的另一件事是，即使您选择编写自定义 GUI 和/或表示层，NO 方法也有价值（我相信）。也就是说，您可以将其用作构建非常稳固的 pojo 域层的设计工具，然后根据需要对其进行蒙皮。问题是 NO 最初从未以这些术语出售，因此大多数人会将 NO 模式视为全有或全无的事情。

担

于 2009-01-19T23:17:13.370 回答
3

看待这个问题的一种方法是考虑从 Toad 或 MySQL 浏览器之类的用户界面中获得的用户界面之间的区别，其中用户界面是直接从表及其关联的元数据构建的，而熟练的设计师会使用的用户界面为实际应用而开发。如果没有太大的不同，那么对于自动生成框架来说，它应该是相当容易实现的目标。

正如您所说，有些问题可以很好地与这种自动生成一起工作，而有些则不能。在我看来，关键是您在用户界面中公开的实现模型（或其部分）与用户概念模型的映射程度。其次，应用程序的行为可以如何通过一组有限的用户界面组件来表达（假设这是一个通用的 UI 生成框架）。

这篇文章“用户界面的通用模型”可能会引起您的兴趣。

于 2009-01-18T10:51:17.407 回答
2

我认为自动生成 UI 的想法有很大的潜力，特别是对于您的普通表单和表格布局数据库用户界面。然而，即使有一个人也需要在循环中，有能力覆盖输出而不会被下一次再生覆盖。

我怀疑如果交互设计师更多地参与到生成算法的开发中，自动生成的 UI 在今天会更加成功。我的印象是，从历史上看，这些系统的创建者不知道要包含哪些与 UI 相关的元数据或如何使用它。为字段指定标签、值范围、格式和顺序是一个开始，但需要更多高级信息。尤其是缺乏对任务和用户角色的充分建模，以及一些基本的 UI 样式指南级原则。

例如，Oracle 的 Designer 2000 在模型中不仅包括实体和关系，而且还包括功能层次结构形式的任务，因此走上了正确的道路。然后他们通过误用此元数据（例如，假设深度总是比广度更受欢迎）并在生成 UI 时包含基本缺陷（例如，一次只能打开一个主窗口）来搞砸它。结果是 IU 甚至不符合 Oracle 自己的应用程序用户界面标准。

于 2009-01-18T16:46:12.117 回答
2

我见过几个使用“裸对象”方法（不是框架，AFAIK）的失败项目（我被聘为一个相当昂贵的顾问来帮助构建替代品的案例）——所有这些项目都使用简单粗暴的 UI，并且工作正常在一个项目中替换了许多 UI，该项目在其最初的化身中具有类似的方法（整个应用程序是通过上下文菜单和属性表访问的对象树 - 这是大约 1998 年的 NetBeans 2.0 - IDE 作为一个巨大的分层 JavaBean ）。

底线是，你的用户并不关心你的架构，他们关心的是在你能想出的最容易理解的交互集合中完成他们需要做的事情。如果这恰好与您的架构相一致，那么您将度过幸运的一天——但这确实是偶然的。试图强迫用户关心（甚至知道）你的架构是没有人愿意使用的软件的秘诀。

代码通常需要围绕两个不总是兼容的目标进行设计：

  1. 可维护性——不写代码的人也能看懂代码
  2. 稳定性和性能——即代码要求计算机物理执行的活动都是可能的，并且可以在合理的时间范围内完成

为满足这两个目标而创建的抽象和代码结构非常非常罕见地映射到任何类型的用户界面元素。有时，如果您的听众是技术人员，您几乎可以侥幸逃脱。但即使在那里，您也可能会在对程序员和机器有意义的架构之上至少使用“表示层”适配器层来取悦更多用户。

于 2010-08-30T23:53:02.057 回答
2

快速建立一个基本的用户界面，让客户试用系统并创建测试数据必须是有价值的。Naked Objects 框架可以帮助“<strong>bootstrapping”，即使您必须在发布之前将其替换为“手工制作”的 UI。

在我工作过的大多数系统中，都有很多简单的家务表。所有这些表格都需要一个 UI 来编辑和查看它们等。这些简单的编辑器保持一致也很有价值。在这里，一个裸对象框架可以节省大量时间，即使主要的“日常”UI 是“手工制作”的</p>

于 2010-06-22T08:39:04.740 回答