如何在 JSF + Spring + Hibernate 中使用 DTO答案

【问题标题】：How to use DTO in JSF + Spring + Hibernate如何在 JSF + Spring + Hibernate 中使用 DTO
【发布时间】：2011-04-19 20:06:55
【问题描述】：

假设我是关于 DTO 主题的新手。我不明白将 DTO 与 JSF、Spring 和 Hibernate 结合使用是否正确。
让我解释一下，到目前为止，我在业务层和表示层都使用了直接从数据库创建的实体 bean。现在我决定尝试使用 DTO 方法，但我不明白他们如何提供帮助。
例如，如果我有两个类 User 和 Message，并且一个用户关联了更多消息；如何从数据库中填充 DTO？还是我在业务层手动填充 DTO？有人可以发布一个关于如何使用 DTO 的示例吗？

提前谢谢你。问候，罗伯托

【问题讨论】：

标签： java hibernate spring jsf dto

【解决方案1】：

DTO 代表数据传输对象。它应该是一个普通的 Javabean 类，没有任何 API/架构特定的限制，例如 JSF、JPA 或 Spring 注释。 IE。它不应包含任何指向外部 API 的 import 或 FQN。唯一的目标是能够在大型模块化 Web 应用程序的不同架构之间传递数据。

例如，如果您不想使用 JPA/Hibernate 实体 bean 作为 JSF 托管 bean 和视图的模型属性，因为由于某些过度限制的业务或模块化原因，它们可能无法传递到 EJB 类之外，那么您需要创建此类的副本并自己映射松散的属性。基本上：

UserEntity userEntity = em.find(UserEntity.class, id);
UserDTO userDTO = new UserDTO();
userDTO.setId(userEntity.getId());
userDTO.setName(userEntity.getName());
// ...
return userDTO;

有plenty of libraries 可用，可以通过以下方式轻松进行 bean 到 bean 映射：

SomeLibary.map(userEntity, userDTO);

但是，对于一般的 Web 应用程序，您不需要 DTO。您已经在使用 JPA 实体。您可以继续在您的 JSF bean/视图中使用它们。

仅此问题就表明您实际上根本不需要 DTO。您不受某些特定业务限制的限制。然后，您不应该搜索设计模式，以便将其应用到您的项目中。您应该以过度复杂/不可维护/重复代码的形式搜索真正的问题，以便您可以询问/找到合适的设计模式。通常，重构重复代码几乎会自动引入新的设计模式，而您实际上并没有意识到这一点。

一个很好的例子是当 JPA 实体对于特定目的“太大”时（即实体包含的属性比您实际需要的多得多）。拥有大量这些部分使用的实体是对服务器内存的浪费。为了解决这个问题，您可以仅基于您在 JPQL 中使用 constructor expression 创建和填充的几个属性来创建 DTO 类/子类。

另见：

【讨论】：

我想知道在没有 DTO 的情况下使用（休眠）延迟加载是否会出现任何问题？考虑到我在 spring（事务）服务方法中获取一个父对象，其中包含延迟加载的子对象（即其他域对象的集合）。在这种情况下，如何确保休眠会话保持打开状态，以便稍后获取休眠代理（在 UI 层中）？如果我使用 DTO 并在服务方法中将数据映射到它们，那么我确定我拥有所有数据并且可以安全地关闭会话......对此有什么想法吗？
如果必须更改数据层而不更改表示层怎么办？

【解决方案2】：

填充 DTO 有两种选择 - 手动填充，或者使用 commons-beanutils 或 Dozer 等实用程序。

DTO 背后的总体思想是，它们用于跨架构层传输数据——通常是松散耦合的层，例如通过 Web 服务或 JMS。 DTO 也可以在视图中使用，以便 web 层获取可用于向用户显示的对象，这些对象与实体不同，以避免实体状态管理问题和映射混乱。

但对于典型应用，我认为 DTO 是不必要的。在您的 JSF bean 和视图中使用您的实体，请注意可能的 LazyInitializationException。我的经验表明，在大多数情况下，实体可以用作 DTO（不需要新的类），但要稍微小心一些。而且，无论我在小型项目中看到 DTO，它们只会使事情变得不必要地复杂化。

【讨论】：