Dan Haywood撰写的《 使用裸对象进行域驱动的设计》一书涵盖了使用域驱动设计技术和开源Java框架Naked Objects（现已成为Apache Isis孵化器项目的一部分）进行Java应用程序开发的内容。 在本书中，Dan讨论了Java开发人员如何通过专注于业务域模型来开发和测试域应用程序，并让该框架负责与基础结构相关的代码和配置元素。
InfoQ与Dan谈了这本书，Naked Objects框架及其作为Apache项目组合的一部分的最新提交。 我们还将为读者提供该书的摘录 （第13章-开发域应用程序； 500 KB PDF）。
InfoQ： 哪种类型的应用程序最适合使用像Naked Objects这样的解决方案？
Dan Haywood：对于那些尚未使用过该术语的读者，让我首先快速解释一下“裸对象”是一种架构模式，其思想是直接在面向对象的用户界面中自动公开领域模型对象。不仅是它们的状态（属性和集合），还有它们的行为（我们称为动作）。 您可以将其视为类似于Hibernate之类的ORM。 但是，尽管ORM将域模型反映到持久层中，但是裸对象将域模型反映到表示层中。
裸对象（大写字母）是一个Java框架，实现了裸对象（小写）模式，这是我的书的主题，即使用裸对象的域驱动设计。 从那时起，我们将原始框架以及我在编写本书时编写的许多姊妹项目带入了Apache Incubator。 因此，最初的“裸对象”现在是Apache Isis。
还有一种名为Naked Objects MVC的商业产品，该产品在.NET平台上作为Web应用程序运行，最初是Java框架的端口。 因此，这两种产品具有相似的设计细节，并且我们继续相互借鉴。 因此，当您说“裸对象”时，我将其称为“裸对象模式”，其中Apache Isis和Naked Objects MVC都是实现。
无论如何，对您的问题。 裸对象模式要求您的首要考虑是建立面向对象的域模型，因此它最适合具有复杂业务规则的企业应用程序，希望在此类域模型中表示它们。 这个想法-至少在最初阶段-是快速建立域模型，并通过利用框架直接在用户界面中公开该域模型的能力来获取域专家的反馈。 图片讲一千个字。
但是我怀疑您的问题可能是一种询问“您是否声称裸对象生成的OO UI适合所有应用程序？”。 为了回答这个问题，我发现区分两个主要的应用程序类别很有用。 第一个是那些在组织内部内部使用的应用程序，这些应用程序由熟悉域模型内实体的有经验的用户使用，并且只需要对使用方式施加尽可能少的约束的应用程序。 这些有时称为主权申请。 如果您是开发人员，那么您的IDE可能是您使用最多的主权应用程序，那么您使用它的任何向导的频率是多少？ 而且，如果您使用电话银行服务，那么您还将知道，对一个主权应用程序造成多么令人沮丧的事情是，它在决定工作流程方面过于侵入……我经常发现，另一端的可怜人要求我等她离开当她为我检查我的银行帐户上的一些详细信息时，一个屏幕进入另一个屏幕。 由裸对象生成的通用OO UI不受此限制，因此非常适合此类应用程序。
尽管还有第二类应用程序，有时也称为瞬态应用程序。 这些是仅偶尔使用或由经验不足的用户使用的用户，通常在组织外部（即您的客户），他们不了解或不在乎域模型，只是希望通过系统来完成一些明确定义的目标。 我最喜欢的例子是在机场的值机亭...我只是想上飞机，并有机会选择我的座位。 我不在乎哪架飞机，甚至哪一架飞机都不在乎，我也不在乎飞行员是谁。 这些对我来说并不重要。 对于此类应用程序，公开大量域的通用OO UI显然是不合适的。 相反，我们需要一个公开视图模型而不是实体的应用程序，并且可以在其中自定义UI。 视图模型对象负责管理用户故事的工作流，仅公开相关领域的子集，并隐藏其余领域。 我们发现，一旦了解了这些视图模型，便可以将它们放在这些实体之上。
使用视图模型对象是必需的，但对于瞬态应用而言可能还不够； 我们通常还需要自定义UI。 裸对象模式的两个主要实现（Isis和.NET）都提供了允许自定义UI的查看器。 Isis本身有两个UI，一个提供一组taglib，一个提供一组Apache Wicket组件。 因此，使用这些技术，我们可以构建适用于瞬态应用程序的自定义UI。
综上所述，我认为裸对象与构建任何类型的企业应用程序都相关。 它的优点是可以构建具有复杂业务域的主权应用程序，但是您也可以将其轻松地用于瞬态应用程序。
InfoQ：Naked Objects框架的局限性是什么？
DH：裸物体是一种固执己见的模式，这是绝对正确的，因此，如果您不同意裸露的物体的某些观点，那么您将发现它在某种程度上受到限制。
首先，用户要与之交互的所有内容都必须是某种对象。 正如我已经解释的那样，对于主权应用程序，这些对象很可能是持久化的域实体，但是对于临时应用程序，该对象可能是支持特定工作流的视图模型，并且可能会持久化也可能不会持久化。 我没有太大的局限性，但是值得注意的是，其他架构（例如Spring Web Flow或Struts）会将跟踪工作流的责任不放在对象中，而是放在某种声明性XML标记中，甚至只是放在控制器和视图之间的相互作用。
上面的一个稍微微妙的结果是，不同技术的集成是通过域对象进行的，而不是通过应用程序层或UI层混搭在它们前面。 例如，假设我们想发送一条SMS来确认结帐。 如果您是自己编写UI和应用程序服务层，则可以选择让应用程序层调用SMS服务，并将其视为协调责任。 但是，对于裸对象，您没有机会编写任何应用程序层代码，因此可以通过将域对象调出到SMS服务中来完成。 SMS服务将由接口定义，并且实现将由框架注入到域对象中。 我知道，并不是每个人都对将域服务注入实体感到满意。 我想我只能说我们已经在一些大型实现中使用了它，并且对我们有用。
裸露对象会感到不同的另一个领域-可能仅限于某些领域-是它将某些职责推给了可能位于其他层中的领域对象。 例如，客户上的placeOrder动作可以具有支持的validatePlaceOrder方法，框架将在调用该动作本身之前使用该方法来验证该动作的参数。 也可以使用disablePlaceOrder方法，如果返回非null，则该操作将在UI中显示为灰色。 例如，列入黑名单的客户可能不允许下任何订单，并将通过disable方法指示这一点。 有些人可能会认为这是放错位置的演示文稿。 但是，客户并没有使UI本身变灰； disable方法仅仅是约定，表示层可以通过该约定询问实体。
我们有时听到的另一件事是，裸露的物体仅真正适用于CRUD样式的应用程序。 我必须承认这种批评确实让我感到讨厌，因为尽管裸对象框架确实会自动公开对象状态，但它们也公开了对象的行为。 我的意思是，每个不是属性或集合的公共方法都被视为一种操作，并且将由UI呈现为按钮或链接。 确实，我们有时喜欢谈论行为上完整的领域对象。 这是贫血领域模型反模式的对立面。
尽管如此，目前出去使用裸对象的最大障碍可能是它是一个很小的社区，因此，至少在Java方面，代码库仍然相对较新。 造成这种情况的部分原因是因为我在撰写本书时写了很多东西； 无论如何，这是我们进入Apache孵化器的原因之一，希望扩大用户社区和参与者的规模。 在.NET方面，该框架仅与Microsoft技术（ASP.NET MVC和Entity Framework）集成，因此它更加成熟。 但是，如果相对的“新颖性”处于关闭状态，请注意，您仍然可以使用裸对象对域模型进行原型设计，因为它们毕竟只是POJO。 的确，这是我在书中明确提到的一个主题：使用裸对象进行原型设计，但部署在其他框架上。
InfoQ：Naked Objects框架如何支持基于Service Oriented Architecture（SOA）的应用程序，其中企业Service组件由多个不同的Web应用程序和其他客户端使用？
DH：无论是使用SOA服务的裸对象应用程序还是提供服务，我都可以回答。
对于使用SOA服务，答案很简单：将SOA服务包装在域服务接口中，然后在框架中注册实现，以便将服务注入到每个域对象中。 这种交互可以是同步的也可以是异步的。 没有什么可以阻止域对象发布事件以供企业服务总线上的其他组件拾取。
为了提供SOA服务，至少在Apache Isis上，有几种不同的查看器可用，其中之一将域对象公开为RESTful层。 我们将对象和对象成员映射到标准的HTTP动词，例如，对象上的GET返回对象表示，对象属性上的PUT会修改状态，或者对象动作上的POST会调用该动作。 现在，该表示形式是用XHTML表示的，它具有很好的副作用，即实际上可以从Web浏览器直接查看该表示形式。 我们确实打算提供JSON表示形式，但目前仍在规划中。
InfoQ：Naked Objects目前作为Apache Isis项目处于Apache孵化器状态。 您能否与我们分享Isis项目的下一步步骤和时间表？
DH ：好吧，我们已经迁移了原始Naked Objects框架和我的姊妹项目的所有代码，并更新了所有软件包名称和许可证标头等。我们也建立了网站，并将其发布到Apache快照仓库中。 我们目前正在努力发布第一个0.1版本； 仍然要做的主要事情是使我们的文档保持最新。 我们还有一个快速入门Maven原型，您可以使用它来快速启动和运行。 有关详细信息，请参见网站。
就时间安排而言，我们将一直在Apache孵化器中工作，直到Isis证明拥有一个自我维持的社区为止。 实际上，我预计这将花费18个月到2年的时间，但是需要的时间会很长。 尽管目前社区很小，但是我们其中的那些人深信该方法，并且我们会一直插手直到到达那里。 当然，进入Apache的举动已经开始带来一些好处。 在加入Apache之前，有4或5个人正在参与社区活动。
InfoQ：该项目的未来路线图是什么？
DH ：我们关于加入孵化器的建议是在线的，这反映了我们当时的想法。 总的主题是各个观众的不断发展。 我热衷于继续基于Wicket开发我的查看器，并为RESTful查看器添加JSON支持。 同时，Rob Matthews（Naked Objects的原始架构师，并且仍然参与其中）仍然继续开发他基于taglib的查看器Scimpi，并且其他贡献者也表示有兴趣使用JSF / Facelets，Tapestry和Android开发类似的查看器。 还有一个硕士 其论文项目是用JavaFX实现的RESTful客户端的学生。 我希望他的大学将允许他将完成的项目捐赠给Isis。
正如我已经指出的那样，Isis具有可插拔的体系结构，并且可以开发大约五个主要的API（以及许多其他更细粒度的API）。 其中最重要的可能是对象存储（持久性）API。 我的姊妹项目之一是使用Hibernate持久化RDBMS的实现。 但是Hibernate的许可证与Apache的许可证不兼容，因此我想对其进行修改。 实际上，我们已经提出的一个建议是使用JDO 3.0 / DataNucleus重新实现，这将使我们能够一口气涵盖很多持久性技术。 如果可以的话，我全力删除多余的代码！
孵化过程中的另一个目标是使Isis更易于引导和嵌入，为此，我希望我们有机会通过JSR-299（上下文和依赖注入）公开Isis组件。 例如，仅使用Isis元模型组件并在您自己的应用程序中使用它就很容易，例如，以自定义UI代码驱动域对象的呈现。
我们可能会看到的另一个领域是对其他JVM语言的支持。 Isis已经支持Java和Groovy，并且Isis建立其元模型的方式意味着支持其他语言（Scala，Fantom，Go）应该非常简单。
我可以继续列出Isis的许多想法和方向。 不过，最终，Apache Isis的路线图取决于其社区希望采用的路线。 因此，随着我们逐步毕业，上述任何一项都可能会发生变化。
您可以在项目网站或订阅邮件列表中找到有关Isis的更多信息。 如果有人对.NET上的Naked Objects MVC感兴趣，可以在其网站上进行截屏和免费下载。
183
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
