清洁域模型的最佳实践 [关闭]答案

【问题标题】：Best practices for clean domain model [closed]清洁域模型的最佳实践 [关闭]
【发布时间】：2014-01-09 12:15:45
【问题描述】：

我正在寻找一些开发干净域对象模型的最佳实践。所谓“干净”，我的意思是一个域（或业务）模型，它不会被一堆数据库持久性、xml/json 序列化/反序列化、依赖注入的东西弄得一团糟。例如，我已经阅读了几个关于实现 REST API 的“操作方法”教程。当他们都到了实现“模型”的地步时，他们最终都有一些关于通过 [XmlAttribute] 从“pojo/poco”转换到 xml/json 视图的注释，或者使该字段在通过 [Display/Display Type] 属性的 UI。平台无关紧要，我见过 Java 世界中的混乱（不熟悉其他脚本语言）。

我知道数据传输对象设计模式，因为这些对象可以使用这些属性，但这是唯一的方法吗？ DTO 似乎需要大量对象映射到/从视图到业务层。如果这就是拥有一个干净的域层所需要的，那就太好了，只是寻找反馈。

谢谢

【问题讨论】：

如果 DTO 在 4.0（至少）默认情况下未注释，WCF 将推断数据成员。总是比假设会发生一些魔术要好，但是为什么需要隐式暴露？
我不理解反对票。对文本密集的问题投反对票已成为 SO 的一种趋势。
@aquaraga - 我没有投反对票，但您的评论更适合 MSO。根据我的经验 - SO 的趋势是对显示很少使用特定上下文或努力的问题投反对票。对于标记多种语言的问题尤其如此。如果您不知道您的代码使用哪种语言，那么您可能应该在 PSE 上发布。我在 MSO 上的选民可能同意也可能不同意。
@M.Babcock 我绝对可以看到 OP 在问这个问题之前已经做了一些研究。另外，SO 上有一个“架构”标签，旨在涵盖与语言无关的所有问题。 OP 可能认为 Java 和 .NET 开发人员/架构师可以给出合理的答案：事实证明确实如此（Will Hartung 给出了答案，使用 Java 示例）。

标签： java .net jakarta-ee architecture

【解决方案1】：

简单的事实是，所有这些“注释混乱”都源于对所有“XML 混乱”的拒绝。

以 Java 中的 JPA 和 JAXB 为例，所有这些注释都可以替换为外部 XML 文件，为底层框架描述相同的元数据。在这两种情况下，框架都为未注释的数据提供了“ok”的默认值，但事实上很少有人真正对框架提供的约定优于配置的默认映射感到满意，因此需要进行更明确的配置。

所有这些配置都必须在某个地方以某种方式捕获。

对于许多人和许多应用程序来说，通过注释嵌入的元数据比外部 XML 映射方法更干净、更易于使用。

最后，从 Java 的角度来看，域模型是“只是”对象，注释通常在各自框架之外没有任何影响。但实际上，与框架总是存在一些耦合，并且它们倾向于影响模型中的实现细节。这些并不是特别明显，但一个简单的事实是，当可能有两种方法来建模某些东西时，一种方法对框架“更友好”，对于许多人来说，这足以使决定朝着那个方向发展，而不是在框架之上争取纯粹。

【讨论】：