Java 清洁域模型的最佳实践

我正在寻找一些开发干净域对象模型的最佳实践。我所说的“干净”是指一个域（或业务）模型，它不会被一堆数据库持久性、xml/json序列化/反序列化、依赖注入之类的东西弄得乱七八糟。例如，我已经阅读了几个关于实现RESTAPI的“操作”教程。当它们都实现了“模型”时，它们最终都会有一些注释，说明如何通过[XmlAttribute]将“pojo/poco”转换为xml/json视图，或者通过[Display/Display Type]属性使该字段在UI中更加用户友好。平台不重要，我见过Java世界的混乱（不熟悉其他脚本语言）

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

---

谢谢

简单的事实是，所有这些“注释混乱”都是因为拒绝了所有“XML混乱”而产生的

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

所有这些配置都必须以某种方式被捕获

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

---

最后，从Java的角度来看，域模型是“just”对象，注释通常与各自框架之外的对象无关。但事实上，框架总是有一些耦合，它们往往会影响模型中的实现细节。这些并不是特别引人注目，但简单的事实是，当有两种方法可以对某个对象建模时，其中一种方法对框架“更友好”，对于许多人来说，这足以使决策朝着这个方向倾斜，而不是在框架之上为纯度而战。

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