我知道将实体类和属性复制到DTO中被认为是反模式的，因此通过Exposed domain model模式，相同的@Entity可以用作数据库实体类和DTO服务和MVC层。 （见https://codereview.stackexchange.com/questions/93511/data-transfer-objects-vs-entities-in-java-rest-server-application）
但是假设我们有微服务架构，其中同一组属性在一个具有持久性的项目中用作实体，而在另一个项目中使用DTO作为服务使用第一个属性。在这种情况下，拟议的模式是什么？
因为第二个项目不需要@Entity相关功能，并且如果我们将该类放在共享库中，它将不再需要JPA特定的API和库。另一种方法是再次使用单独的DTO类反模式。
答案 0 :(得分：1)
当您对DTO模型的需求与您的实体模型完全匹配时，您要么处于项目的早期阶段，要么很幸运，您只拥有一个简单的模型。如果您的模型非常简单，那么DTO不会给您带来很多直接的好处。
在某些时候，DTO模型和实体模型的要求会有所不同。想象一下，您向实体/持久性模型添加了一些审计方面，统计信息或非规范化。通常，此类数据永远不会直接通过DTO公开，因此您需要拆分模型。通常，DTO的主要驱动因素是您不需要一直保持所有数据。如果您以例如下拉菜单中只需要标签和对象ID，那么为什么要为这种用例加载整个实体状态？
您在DTO模型上具有批注的事实不应该让您感到那么烦，替代品是什么？类似于XML的映射？手动对象接线？ 如果您的模型直接由第三方使用，则可以使用子类，即使主模型中没有注释，并且在您的项目中有带注释的子类可以扩展主模型。
自从正确实施DTO方法以来，我创建了Blaze-Persistence Entity Views，它不仅可以简化定义DTO的方式，而且还可以提高查询的性能。
如果您有兴趣，我什至举一个external model的示例，该示例使用entity view subclasses保持主模型的清洁。
答案 1 :(得分：0)
谢谢您的回答，但是问题中的重点是微服务（MS）架构，并将来自一个MS的已定义实体POJO重用作另一个PO。从我在微服务上阅读的内容来看，它与另一个问题密切相关-MS应该完全共享任何通用功能和类，还是完全独立？似乎对此没有确定的共识，也没有确定的答案或广泛接受的模式。
根据我最近的经验，这里是我采用的方法，到目前为止效果很好。 在MS之间具有通用功能-是的，以Commons项目的形式添加为对所有MS的依赖性，并且其依赖性设置为可选。共享实体类（将它们公开）-不。
主要原因是实体类与特定MS的数据存储密切相关。并且，由于已建立的规则是MS不应共享数据存储，因此有意义的是不共享那些数据存储的实体类。它帮助MS变得更加独立，并以自己的方式自由管理数据存储。这意味着要进行更多输入，以添加其他DTO类并在它们之间进行转换，但是保持MS独立性是值得权衡的。 Christian Beikov和Maksim Gumerov提到的理由也适用。
我们共享的（共有）是一些通用的功能和帮助程序类（用于云，发现，错误处理，Rest和json配置...）以及纯DTO，其中T是MS之间的转移（其余实体）或邮件有效载荷）。