16

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

4

10 回答 10

10

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

好的:

  • 自动为您的域对象生成 DnD UI,就像 db4o 为持久性所做的那样。
  • 根据 MVC 模式创建者的说法,这就是 MVC 一直以来的意义所在。
  • 该框架仅要求您的域对象 (POJO) 从 AbstractDomainObject 子类化,这就是所有最少的布线。
  • 该框架支持约定 OVER 配置:大量注释没有可怕的 XML 配置文件。
  • 非常适合与 db4o 一起进行原型设计以实现持久性。
  • Hibernate 的开箱即用功能。
  • 就我而言,从下载到 Hello world 应用程序需要 30 分钟。(IntelliJ IDEA IDE)
  • 部署为 JNLP、独立、Web(NOX​​ 嵌入式 Jetty 或 Simpi 风格)和 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 线程修改的,比如说一个 bg worker,这样的对象将
    不会更新它在屏幕上的视图。这会使用例(例如在 DnD 自动生成的 UI 上实时表示邮件队列)无效。(再次)

  • 维克

于 2008-10-30T19:50:10.560 回答
10

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

话虽如此,我绝对喜欢 Django 如何在其 Django 模型中实现裸对象。我喜欢这个框架的大部分东西,我开始相信,它的模型的直接结果,我想分享一些关于架构的令人惊叹的东西:

映射到表列的模型字段在行为上是完整的对象——它们知道它们在应用程序和数据库域中是如何表示的,它们如何在两者之间进行转换,以及它们所持有的信息如何被验证并显示给用户视觉输入。所有这些都在您的模型中使用了一行代码。

管理器附加到模型并提供 CRUD 和集合上的任何通用操作,例如可重用查询(给我最近五篇博文、最常出现的标签等)、批量删除/更新操作以及在实例上执行的业务逻辑。

现在考虑您有一个代表用户的模型。有时,您只想查看用户模型所持有的所有信息的部分视图(重置用户密码时,您可能只需要用户的电子邮件和他的秘密问题)。他们提供了一个 Forms API,可以准确地显示和管理模型数据的一部分的输入。允许对处理用户输入的内容/方式进行任何自定义。

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

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

于 2010-09-15T00:58:06.473 回答
7

它已在爱尔兰成功使用。

我认为它没有更受欢迎的原因是:

  • 您需要对正在使用的工具包充满信心
  • 它使 GUI 成为一个风险因素,而不是一个不费吹灰之力的因素(无论是在技术上还是在可用性测试中)
  • 它不适用于网络(据我所知),这是大多数焦点所在的地方......
于 2008-10-03T15:56:45.993 回答
5

我才看到这个。一些小的更正,否则大多数评论都非常公平。

1)“框架只要求您的域对象(PO​​JO)从 AbstractDomainObject 子类化,这就是所有最少的布线。”

裸对象不需要从 AbstractDomainObject 子类化域对象,尽管这通常是最方便的做法。

如果您不想继承,您只需提供 IDomainObjectContainer 类型的属性,然后框架将在创建或检索对象时将容器注入到您的对象中。该容器具有 Resolve()、ObjectChanged() 和 NewTransientInstance() 方法,它们是您必须使用的与框架的三个极简接触点,以便框架与您的域对象保持同步。

2) '非常适合与 db4o 一起进行原型设计以实现持久性'。我们非常热衷于使用 db4o 的想法,但我不知道有谁让 Naked Objects 和 db4o 一起玩。如果有人做过这件事,我想听听更多关于它的信息。

3) '在 smalltalk 和裸对象社区中所拥护的公民程序员的一般模型......'。我们从来没有支持过这个想法,我也不同意。Naked Objects 并不是要鼓励用户编程。我坚信专业开发人员的角色 - Naked Objects 只是帮助他们编写更好的软件和更高效。

理查德

于 2008-11-19T12:30:42.597 回答
4

去年左右我玩过它,并得出结论它很容易使用。

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

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

如果您需要任何不同的东西,使框架适应您的愿望可能比使用为支持您想要的应用程序而编写的框架要多得多的工作。

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

于 2008-10-03T19:17:56.353 回答
2

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

还有其他问题,例如很难控制外观和感觉,对于已经习惯了窗口模型的人来说,它们是违反直觉的。还有一些建模问题,因为并非所有应用程序域都适合直接对象表示。

在 smalltalk 和裸对象社区中所拥护的“公民程序员”的一般模型也被认为是一个值得怀疑的想法。大多数用户似乎对自己更改功能并不太在意,因此在对象中思考并不是那么有用。

于 2008-10-03T16:03:08.167 回答
2

可能它没有得到更多关注的原因是 J2EE 世界已经习惯于在应用程序上堆积如此多的层,以至于裸对象显得幼稚。

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

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

于 2008-10-04T01:31:12.870 回答
2

我想 NakedObject 肯定有它的相关性,而且开发人员社区重新关注真正支付给他们的东西:业务不仅仅是时间。相反,我们大部分时间都花在基础设施、协议和所有那些技术垃圾上。我见过这样的构建应用程序,我什至按照主流自己做了一些,告诉你分层系统总是一件好事。最糟糕的是,如果你问一些开发人员他们所在的公司从事什么样的业务,你会发现至少有一些在公司工作多年但对业务没有深入了解的人。然而,

于 2008-12-08T15:48:53.550 回答
2

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

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

顺便说一句,最近我们正在努力为 NO 4.0 创建基于 GWT 的 DnD 查看器。

于 2010-04-30T06:23:44.180 回答
0
  • 技术的广泛使用与技术质量没有很强的相关性。
  • 裸对象系统很难与类型对象结合使用:如果我销售不同种类的产品并且需要针对不同产品的不同数据,则很难将数据限制在产品类型上。
  • 他们转换许可证时没有失去动力。(到 GPL+Commercial,而不是最近转向 Apache)

你看过jmatter吗?

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

于 2008-11-23T09:40:51.537 回答