当前位置: 首页 > 面试题库 >

在休眠实体和数据传输对象之间进行转换的良好模式是什么?

那正初
2023-03-14
问题内容

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

在ejb3中使用数据传输对象被认为是最佳实践

此处提到的因素之一是,如果域模型发生更改,则在Web服务的情况下,一组DTO将保护使用者。

即使看起来它将为我的项目添加大量代码,这种推理也似乎是合理的。

是否可以使用一种好的设计模式将Hibernate实体(实现一个接口)转换为实现相同接口的DTO?

因此,假设以下两个实现都为“ Book”,则需要将BookEntity.class转换为BookDTO.class,以便让JAXB序列化并返回。

同样,整个前景对我来说似乎令人怀疑,但是如果有好的模式可以帮助您完成这种转换,那么我很想获得一些见识。

也许有一些有趣的方式可以通过反射进行转换?还是我没有想到的“构建者”模式?

我是否应该忽略DTO模式并传递实体?


问题答案:

我是否应该忽略DTO模式并传递实体?

我的偏好通常是“是”。我不喜欢仅出于架构或图层纯洁性而创建的并行层次结构的想法。

DTO模式的最初原因是当将实体EJB传递到视图层时,EJB 1.0和2.0应用程序中的聊天过多。解决方案是将实体bean状态放入DTO。

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

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

我意识到有些人会不同意。我只是提供我的意见。这不是唯一的方法,也不一定是“正确”的方法。这是我的偏爱。



 类似资料:
  • 问题内容: 关于如何在Hibernate实体和Web服务要返回的数据传输对象之间进行转换,我也有类似的问题和疑虑,如以下问题所述: 此处提到的因素之一是,如果域模型发生更改,则在Web服务的情况下,一组DTO将保护使用者。 即使看起来它将为我的项目添加大量代码,这种推理也似乎是合理的。 是否可以使用一种好的设计模式将一个Hibernate实体(实现一个接口)转换为一个实现相同接口的DTO? 因此,

  • 我需要用UI组件更新模型类的数据,同时用数据对象中的更改更新UI组件。详细说明了大量数据依赖于其他数据。E.A.:A和B的总和。这个总和需要在UI上显示并存储在模型类中。 在实际情况下,我有大约58个可编辑的字段,混合了文本和数字。和一半的计算字段。 第一个步骤是将DocumentListeners添加到所有可编辑的UI字段中。当发生更改时,它们更新模型中的数据,并调用一个方法来更新UI中的所有字

  • 问题内容: 当我使用@Entity注释类并尝试解决依赖关系时,我可以在两个不同的包javax.persistence.Entity和org.hibernate.annotations.Entity中选择包。 javax包是JPA的实体注释,但是为什么会有休眠的实体注释,它与JPA的注释有区别?仅仅是允许定义更多属性的扩展吗? 问题答案: 具有一些尚未标准化的额外属性。仅当直接使用hibernate

  • 问题内容: jpa和休眠之间的异同是什么? 问题答案: JPA(Java持久性API)是持久性提供程序要实现的接口。Hibernate就是这样的JPA实现。

  • 问题内容: 我最近听到有人说数据传输对象(DTO)是一种反模式。 为什么?有哪些选择? 问题答案: 一些项目的所有数据都有两次。一次作为域对象,一次作为数据传输对象。 这种重复需要付出巨大的代价,因此该架构需要从这种分离中获得巨大的收益,才能使其值得。

  • 在我的Spring Boot项目中,我使用Hibernate,基本上我们有三种对象 在控制器层中使用的DTO对象 业务对象—业务对象是我们在整个应用程序中使用的对象 实体/域对象-用于JPA层 当我们准备好保存数据时,我们将业务对象转换为域/实体对象 当我们准备将其发送给客户机/控制器时,我们可以将实体对象转换为业务对象,然后将此业务对象转换为DTO对象。 理想情况下,我被告知将BOs更改为- 我