裸露的物体。好或坏 [已关闭]

根据我使用NOF 3.0.3的经验...

好处：

• 自动为域对象生成 DnD UI，就像 db4o 对持久性所做的那样。
• 根据MVC模式创建者的说法，这就是MVC一直以来的本意。
• 该框架仅要求从抽象域对象（AbstractDomainObject）子类化，这是所有最小的连接。
• 该框架支持约定而不是配置：大量的注释没有可怕的XML配置 giles。
• 非常适合原型设计以及用于持久性的 db4o。
• 休眠的开箱即用功能。
• 在我的情况下，我需要从下载到Hello world应用程序大约30分钟（ IntelliJ IDEA IDE）
• 部署为JNLP，独立，Web（NOX嵌入式Jetty或Scimpi风格）和Eclipse RCP。
• 当您在论坛中寻求帮助时，NOF团队随时为您服务。
• 裸体物体图案是一个很棒的主意，帮自己一个忙，花点时间摸索它。
• 拖放GUI周围有很多可用性的火焰，但是如果您的潜在最终用户根本无法使用DnD UI，那么您无论如何都会遇到深深的麻烦。

坏处：

• 没有我能想到的。

有点丑陋：

• 不允许使用 Swing 组件，因此请告别 JGoodies 和所有您最喜爱的 Swing 组件集。UI组件是定制的;为了让您了解它们看起来像90年代早期的VB控件。但是有一个SWT端口正在开发中。
• 长字符串的多行行字段存在一些问题。（NOF 3.0.3）
• 图像的DnD UI有点错误。
• 仅当从 UI 修改域对象时，才会触发 getters n setters 的验证代码。（由于我的n00bness，这可能是错误的，希望NOF提交者纠正我）

• 如果一个对象是从非ui线程修改的，比如说一个b.g.worker，这样的对象不会
  在屏幕上更新它的视图。这将使用例失效，例如在 DnD 自动生成的 UI 上实时表示邮件队列。（再次）

• 维科

我已经研究裸体方法一年多了，我甚至还没有开始触及它为系统架构提供的可能性的表面。但是，为了正确使用它，它需要您创建范式转换并寻求完整的OO解决方案，并从诉诸功能鸭子磁带中恢复过来，因为该范式似乎只有在您创建允许高级开发的设计时才有效。

话虽如此，我非常喜欢Django如何在Django模型中实现裸对象。我喜欢这个框架的大多数事情都是，我开始相信，它是模型的直接结果，我想分享一些关于架构的惊叹：

映射到表列的模型字段在行为上是完整的对象 - 它们知道如何在应用程序域和数据库域中表示它们，如何在两者之间转换它们，以及它们所保存的信息如何被验证并以可视方式显示给用户以进行输入。所有这些都通过模型中的一行代码来利用。哇！

经理附加到模型，并提供 CRUD 和对集合的任何通用操作，例如可重用查询（给我最近五篇博客文章、最常出现的标记等）、批量删除\更新操作以及在实例上执行的业务逻辑。哇！

现在假设您有一个表示用户的模型。有时，您只想部分查看用户模型持有的所有信息（重置用户密码时，您可能只需要用户的电子邮件和他的秘密问题）。他们提供了一个 Forms API，该 API 仅显示和管理部分模型数据的输入。允许在处理用户输入时对内容/方式进行任何自定义。哇！

最终结果是，您的模型仅用于描述您用于描述特定域的信息;经理对模型执行所有操作;表单用于创建视图和处理用户输入;控制器（视图）仅用于处理HTTP动词，如果它们与模型一起使用，则仅通过管理器和表单;视图（模板）用于演示文稿（无法自动生成的部分）。恕我直言，这是一个非常干净的建筑。可以在不同的模型中使用和重用不同的管理器，可以为模型创建不同的表单，不同的视图可以使用不同的管理器。这些分离度使您能够快速设计应用程序。

您创建了一个智能对象生态系统，并从它们的互连方式中获取整个应用程序。前提是它们是松散耦合的（让它们以不同的方式进行通信的可能性很大），并且可以轻松修改和扩展（针对该特定要求的几行），遵循范例，您确实可以获得一个架构，其中组件编写一次，然后在其他项目中重用它。这是MVC应该一直以来的样子，但我经常不得不从头开始写一些东西，即使我在几个项目前做了同样的事情。