什么是在hibernate实体和数据传输对象之间进行转换的好模式？

Question

我有类似的问题和关注如何在Web服务返回的Hibernate实体和数据传输对象之间进行转换,如本问题所述:

这里提到的一个因素是,如果域模型发生变化,一组DTO将在Web服务的情况下保护消费者.

即使它似乎会为我的项目添加大量代码,但这种推理似乎是合理的.

有没有一个好的设计模式可以用来将Hibernate实体(实现接口)转换为实现相同接口的DTO？

因此,假设以下两个实现'Book',我需要将BookEntity.class转换为BookDTO.class,以便我可以让JAXB序列化并返回.

同样,这整个前景对我来说似乎都很可疑,但如果有很好的模式来帮助处理这种转换,我很乐意获得一些见解.

是否有一些有趣的方式通过反射转换？还是一个我没想过的"建设者"模式？

我应该忽略DTO模式并传递实体吗？

Answer 1

我应该忽略DTO模式并传递实体吗？

我的偏好通常是"是".我不喜欢为了建筑或图层纯度而创建的并行层次结构的想法.

DTO模式的最初原因是当将实体EJB传递给视图层时,EJB 1.0和2.0应用程序中的过度干扰.解决方案是将实体bean状态放入DTO.

通常用于创建DTO的另一个原因是禁止视图层进行修改.在这种情况下,DTO是不可变对象,没有任何行为.他们什么都不做,只是将数据传送到视图层.

我认为DTO是一种核心J2EE模式,它已成为一种反模式.

我意识到有些人不同意.我只是提出我的意见.这不是唯一的方法,也不一定是"正确"的方式.这是我的偏好.

我想如果你完全控制了整个堆栈,那么这是有效的.但是,如果有两个或更多UI使用您的服务而不分离图层是危险的.如果你去更改你发送它们的对象,它将打破你对你服务的调用.您不能指望服务的所有实现者在更改图层时更新其代码.因此层分离的核心原因,但每个上下文都不同.你需要先了解它. (3认同)
我也普遍拒绝实施DTO--没有足够的价格.我实现了DAO类并使用Hibernate的工具从数据库生成/反向工程模型类.那是好事. (2认同)

Answer 2

在DTO的所有快乐踢中,需要有逆向观点.

tl; dr - 它有时仍然有用.

DTO的优点是您不必为您的域类添加数百个注释.

你从@Entity开始.还不错.但你需要JAXB所以你添加@XmlElement等 - 然后你需要JSON,所以你添加的东西像@JsonManagedReference为杰克逊做关系的正确的事情,那么你添加等等,等等等等循环往复.

很快你的POJO就不再那么简单了.有时阅读"域驱动设计".

此外,您可以"过滤"一些您不希望视图了解的属性.

Answer 3

我们不应该忘记实体对象在处于托管状态时不易处理.这使得他们传递给GUI形式存在问题.更确切地说,急切地处理子对象.这不能在会话之外完成,因为会导致异常.因此,他们要么必须从实体经理被驱逐(分离),他们必须转换为适当的DTO.除非cource有一种我不知道的模式,否则我很高兴知道.