最近，我接触了裸露的物体。它看起来像一个相当不错的框架。但是我看不到像Spring这样的广泛使用的语言。那么，为什么这个框架没有得到任何主流应用程序的认可。如我们所见，它有什么缺点？

解决方案

它已在爱尔兰成功使用。

我认为它没有受到更多欢迎的原因是：

• 我们需要对使用的工具包充满信心
• 它使GUI成为一个风险因素，而不是轻而易举地(在技术和可用性测试方面)
• 据我所知，它不适用于网络，这是目前大多数关注的地方...

Gareth提出了一些出色的观点。

还有其他问题，例如很难控制外观和感觉，并且与习惯于窗口模型的人有悖常理。还有一个建模问题，因为并非所有的应用程序领域都适合直接使用对象表示。

在小谈话和裸对象社区中拥护的"公民程序员"的通用模型也成为一个有问题的想法。大多数用户似乎并没有为自己更改功能而烦恼，因此在对象中进行思考并不是那么有用。

我去年左右玩过它，并且得出结论说，使用它非常容易。

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

我的结论是，Naked Objects对于内部应用程序确实非常有用，该应用程序在概念上处理记录，例如库存应用程序或者票据处理应用程序。

如果我们需要任何其他使框架适应愿望的方法，可能比使用为支持所需应用程序而编写的框架要耗费更多的工作。

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

它没有得到更多关注的原因可能是因为J2EE世界已经习惯于在应用程序上堆积很多层，以至于裸对象显得天真。

我们的服务在哪里？意思是任何裸露的物体都可以使我立即访问数据库吗？如果我们需要使用RMI调用公开应用程序怎么办？

再加上市场上没有太多东西，因为这将开发成功应用程序的负担直接放在应用程序开发人员而不是框架开发人员身上：

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

优点：

• 自动为域对象生成DnD UI，就像db4o为持久性所做的一样。
• 根据MVC模式创建者的说法，这就是MVC始终意味着的含义。
• 该框架仅要求将域对象(PO​​JO)从AbstractDomainObject继承下来，这就是所有最少的接线。
• 该框架偏向于约定OVER配置：许多批注没有异常的XML配置。
• 非常适合与db4o一起用于持久性的原型制作。
• Hibernate的开箱即用功能。
• 就我而言，我需要大约30分钟的时间从"下载到Hello World"应用程序。 (IntelliJ IDEA IDE)
• 部署为JNLP，独立，Web(NOX​​嵌入式Jetty或者Scimpi风格)和Eclipse RCP。
• 当我们在论坛上寻求帮助时，NOF团队随时为我们服务。
• Naked Object Pattern是一个很棒的想法，请帮自己一个忙，花点时间来解决这个问题。
• 拖放GUI周围出现了很多可用性问题，但是如果最终用户根本无法使用DnD UI，那么无论如何我们都将面临巨大的麻烦。

坏处：

• 我没有想到的。

有点丑陋：

• 不允许使用Swing组件，所以请告别JGoodies和所有我们喜欢的Swing组件集。 UI组件是定制的。让我们知道它们看起来像90年代初期的VB控件。但是有一个SWT端口正在开发中。
• 长字符串的多行行字段存在一些问题。 (NOF 3.0.3)
• 用于图像的DnD UI有点问题。
• 仅当从UI修改域对象时，才触发getter和setter的验证代码。 (由于我的n00bness，这可能是错误的，希望NOF提交者纠正我)
• 如果对象是通过非UI线程修改的，则假设b.g.工作人员，此类对象将不会更新其在屏幕上的视图。这使用例无效，例如在DnD自动生成的UI上实时表示邮件队列。 (再次)
• 威科

我只看过这个。进行了一些小的更正，否则大多数评论都非常公平。

1)"该框架仅要求将域对象(PO​​JO)从AbstractDomainObject继承下来，这就是所有最少的接线。"

裸对象不需要将域对象从AbstractDomainObject子类化，尽管这通常是最方便的操作。

如果我们不想继承，则只需提供IDomainObjectContainer类型的属性，然后框架将在创建或者检索对象时将一个容器注入到对象中。容器具有Resolve()，ObjectChanged()和NewTransientInstance()的方法，这是我们必须使用的与框架的三个最低限度的联系点，以便框架与域对象保持同步。

2)"非常适合与db4o一起用于持久性的原型制作"。我们非常热衷于使用db4o的想法，但是我不知道有人让Naked Objects和db4o一起玩。如果有人这样做，我想听听更多。

3)"在小型对话和裸对象社区中拥护的公民程序员的一般模型……"。我们从未拥护这个想法，我也不同意。 Naked Objects与鼓励用户编程无关。我坚信专业开发人员Naked Objects的作用只是帮助他们编写更好的软件和提高生产力。

理查德

• 技术的广泛使用与技术质量没有密切关系。
• nudeobject系统很难与类型对象结合使用：如果我要出售不同类型的产品，并且对于不同的产品需要不同的数据，则很难将数据约束在产品类型上。
• 他们换了证照，没有失去动力。 (改为GPL + Commercial，而不是最近移至Apache)

你看过jmatter了吗？

[编辑]
还有一个：如果我们可以交付的话，这对非程序员来说是显而易见的。 Spring在技术领域非常重要，这并不意味着开发人员必须与用户交流。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。大型组织不这样做。

我猜想NakedObject肯定有其相关性，而且开发人员社区将重心更多地集中在真正为他们支付的费用上：业务。
取而代之的是，我们大部分时间都花在基础架构，协议和所有技术上的废话上。我已经看到过这种错综复杂的应用程序，甚至在主流之后我也做了一些自己的事情，告诉我们对系统进行分层始终是一件好事。最糟糕的是，如果我们问一些开发人员他们所从事的公司从事哪种业务，我们会发现至少有一些人在该公司工作了多年而未加深对业务的了解。

但是，我不相信NakedObject会吸引绝大多数开发人员(即使是那些受DomainDrivenDevelopment启发的开发人员)，仅仅是因为人们喜欢构建UI并把工作从他们那里拿走，将他们的工作导向业务需求，根本不是他们想要：我们都是VB混蛋。

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

因此，如果解决方案需要某种"概念验证"，则可以使用NO。但是对于生产而言，准备好将资源投入到NO框架的开发中。

顺便说一句，最近，我们正在基于NO的GWT创建DnD查看器。

我从事裸对象方法的研究已有一年多了，我什至还没有开始探讨它为系统架构提供的可能性。但是，要正确地利用它，就要求我们创建一个范式转换，并寻求完整的OO解决方案，并从诉诸功能性的鸭嘴式磁带恢复到原来的状态，因为该范式似乎仅在我们创建允许高层开发的设计时才起作用。

话虽如此，我绝对喜欢Django如何在Django模型中实现裸对象。我喜欢该框架的大多数事情都是，我相信，这是它的模型的直接结果，我想分享一下有关该体系结构的一些惊叹之处：

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

管理器添加在模型上，并提供CRUD和对集合的任何常规操作，例如可重用的查询(给我最后五篇博客文章，出现最多的标记等)，批量删除\更新操作以及在实例上执行的业务逻辑。哇！

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

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

段落数量不匹配