裸体物体。是好是坏

Question

我最近接触过裸体物体。它看起来像一个相当不错的框架。但是我并没有像Spring那样广泛使用它。那么为什么这个框架没有获得任何主流应用程序的功劳你看到它的缺点是什么？

Answer 1

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

好处：

• 自动为您的域对象生成DnD UI，就像db4o为持久性所做的那样。
• 根据MVC模式创建者的说法，这就是MVC一直以来的意思。
• 该框架仅要求您的域对象（PO​​JO）从AbstractDomainObject进行子类化，这是所有最小的布线。
• 该框架支持约定OVER配置：许多注释没有令人讨厌的XML配置giles。
• 非常适合原型设计以及db4o for persistence。
• Hibernate的开箱即用功能。
• 在我的情况下，我需要从下载到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修改域对象，则仅触发getter n setter的验证代码。 （由于我的n00bness，这可能是错误的，希望NOF提交者纠正我）

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

• 韦科

Answer 2

我一直在研究裸体物体方法已有一年多了，我甚至还没有开始为它的系统架构提供可能性。为了正确地利用它，它需要你创建一个范例转换并寻找完整的OO解决方案并从求助于功能性的鸭子磁带，因为范式似乎只有在你创建一个允许高级开发的设计时才有效。

话虽如此，我非常喜欢Django如何在它的Django模型中实现裸体对象。我喜欢这个框架的大部分内容都是，我所相信的，它是模型的直接结果，并且我想分享关于架构的一些哇哇：

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

管理员附加到模型并提供CRUD和集合上的任何通用操作，例如可重复使用的查询（给我最后五篇博文，最常见的标签等），批量删除\更新操作以及执行的业务逻辑实例。的哇！

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

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

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

Answer 3

已成功使用here in Ireland。

我认为它之所以不受欢迎的原因是：

• 您需要对使用的工具包充满信心
• 它使GUI成为风险因素，而不是简单的（技术上和可用性测试中）
• 它不适用于网络（据我所知），这是大多数焦点都存在的地方......

Answer 4

我刚看到这个。一些小的修正，否则大多数评论都非常公平。

1）'框架只要求你的域对象（PO​​JO）从AbstractDomainObject中被子类化，这是所有最小的布线。'

Naked Objects不要求将域对象从AbstractDomainObject子类化，尽管这通常是最方便的事情。

如果您不想继承，那么您需要做的就是提供IDomainObjectContainer类型的属性，然后框架会在创建或检索对象时将一个容器注入到对象中。容器具有Resolve（），ObjectChanged（）和NewTransientInstance（）的方法，它们是您必须使用的框架的三个极简主义接触点，以便框架与您的域对象保持同步。

2）'适用于原型设计以及db4o for persistence'。我们非常热衷于使用db4o的想法，但我不知道有谁让Naked Objects和db4o一起玩。如果有人这样做了，我想听听更多关于它的事情。

3）'在小谈话和裸体对象社区中支持的citzen程序员的一般模型......'。我们从未支持过这个想法，我不同意。裸体对象不是鼓励用户编程。我坚信专业开发人员的作用 - Naked Objects只是帮助他们更好地编写更好的软件。

理查德

Answer 5

我去年玩过它，结论很容易合作。

Naked Objectsis的优势在于您可以免费获得根据您的数据模型构建的GUI。缺点是典型的用户不会将他的过程视为记录集合。

我的结论是Naked Objects非常适合内部应用程序，它在概念上处理记录，如库存应用程序或帐单处理应用程序。

如果你需要任何不同的东西，那么根据你的意愿调整框架可能比使用为支持你想要的应用程序而编写的框架要多得多。

顺便说一下，有一个Web渲染选项;请参阅Naked Objects Demo上的演示。

Answer 6

Gareth提出了一些很好的观点。

还有其他问题，例如难以控制外观和感觉，而且对于习惯了窗口模型的人来说，这些问题是违反直觉的。还存在一些建模问题，因为并非所有应用程序域都能很好地直接表示对象。

小公民和裸体社区所支持的“公民程序员”的一般模式也是一个值得怀疑的想法。大多数用户似乎并没有因为自己更改功能而感到非常困扰，因此在对象中思考并没有那么有用。

Answer 7

它可能没有得到更多关注的原因可能是J2EE世界已经习惯于将如此多的层堆积到应用程序上，而裸体对象则是天真的。

我们的服务在哪里？你是说任何裸体对象都能让我立即访问数据库？如果我们需要使用RMI调用公开应用程序怎么办？

另外，没有那么多的市场，因为它将开发成功应用程序的负担直接放在应用程序开发人员而不是框架开发人员身上：）

Answer 8

我认为NakedObject肯定有它的相关性，而且开发者社区重新关注真正付出代价的是时间：业务。 相反，我们主要把时间花在基础设施，协议和所有技术上。我已经看到这样的错过构建应用程序，我甚至做了一些自己跟随主流，教你分层系统总是一件好事。最糟糕的是，如果你问一些开发人员他们所从事的公司是做什么样的业务，你会发现至少有一些人为公司工作多年而没有深入了解业务。 但是，我不认为NakedObject会吸引绝大多数开发人员（即使是那些受到DomainDrivenDevelopment启发的开发人员）仅仅是因为人们喜欢构建UI并将这项工作从他们那里拿走，将他们的工作指向企业需求，根本就不是他们想要什么：我们都是VB混蛋。

Answer 9

NakedObjects（NO）适用于快速原型制作。您可以专注于域模型，而不关注GUI，DB和解决方案的其他部分。对于生产，它需要在NakedObjects框架本身中进行大量改进（错误修复，数据映射，gui等）。

因此，如果您需要为您的解决方案获得某种“概念证明”，您可以使用NO。但是为了生产，准备将资源投入到NO框架的开发中。

BTW，最近我们正致力于基于GWT为NO 4.0创建DnD查看器。

Answer 10

• 技术的广泛使用与技术质量没有很强的相关性。
• 裸体系统很难与类型物体结合使用： 如果我销售不同类型的产品并且需要不同产品的不同数据，则很难限制产品类型的数据。
• 切换许可证时没有失去动力。 （对GPL + Commercial，而不是最近转向Apache）

你看过jmatter吗？

[编辑] 还有一个：如果你能提供，它对非程序员来说是显而易见的。 Spring非常注重技术领域，NO意味着开发人员必须与用户交流。大型组织不这样做。