关于如何在Hibernate实体和Web服务返回的数据传输对象之间进行转换，我遇到了类似的问题和担忧，如以下问题中所述：
这里提到的一个因素是，如果域模型发生变化，一组DTO将在Web服务的情况下保护消费者。
尽管看起来它会为我的项目添加大量代码，但这种推理似乎是合理的。
有没有一个好的设计模式，我可以用来将Hibernate实体（实现接口）转换为实现相同接口的DTO？
因此，假设以下两个实现“Book”，我需要将BookEntity.class转换为BookDTO.class以便我可以让JAXB序列化并返回。
同样，这整个前景对我来说似乎很可疑，但如果有很好的模式来帮助处理这种转换，我很乐意获得一些见解。
有没有一些有趣的方法可以通过反射进行转换？还是我没有想到的“构建者”模式？
我是否应该忽略 DTO 模式并传递实体？
我是否应该忽略 DTO 模式并传递实体？
我的偏好通常是“是”。我不喜欢仅仅为了架构或层纯度而创建的并行层次结构的想法。
DTO 模式的最初原因是在将实体 EJB 传递到视图层时，EJB 1.0 和 2.0 应用程序中的过度闲聊。解决方案是将实体 Bean 状态置于 DTO 中。
创建 DTO 时通常给出的另一个原因是禁止视图层进行修改。在这种情况下，DTO 是不可变的对象，没有任何行为。它们只执行任何操作，只是将数据传送到视图图层。
我认为DTO是一个核心J2EE模式，已经成为一个反模式。
我意识到有些人会不同意。我只是在提供我的意见。这不是做到这一点的唯一方法，也不一定是“正确”的方法。这是我的偏好。
在DTO的所有快乐踢中都需要有一个相反的观点。
tl;dr - 它有时仍然有用。
DTO 的优点是，您不必向域类添加大量注释。
你从@Entity开始。没那么糟糕。但是你需要JAXB，所以你添加@XMLElement等 - 然后你需要JSON，所以你添加一些东西，比如@JsonManagedReference让Jackson对关系做正确的事情，然后你无限添加等等等等。
很快，你的POJO就不再那么简单了。有时阅读有关“领域驱动设计”的信息。
此外，还可以“筛选”一些不希望视图了解的属性。
