如何在JSF + Spring + Hibernate中使用DTO [英] How to use DTO in JSF + Spring + Hibernate
问题描述
我无法理解是否将DTO与JSF，Spring和Hibernate配合使用是正确的。
让我解释一下，到目前为止，我已经使用了直接从数据库，无论是业务层还是表示层。
现在我决定尝试使用DTO方法，但我无法理解它们如何提供帮助。
例如，如果我有两个类User和Message，并且用户有更多关联的消息;我怎样才能从数据库中填充DTO？或者，我手动在业务层填充DTO？
可以有人发表如何使用DTO的例子吗？
预先感谢您。
Regards，
Roberto
DTO代表数据传输对象。它应该是一个普通的vanilla Javabean类，没有任何API /体系结构特定的限制，如JSF，JPA或Spring注释。即它不应包含任何指向外部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（））;
// ...
返回userDTO;
有大量的图书馆可用，这使得豆到bean的映射容易以下方式：
SomeLibary.map（userEntity，userDTO）;
但是，对于普通的web应用程序，您不需要DTO。您已经在使用JPA实体。你可以继续在你的JSF bean / view中使用它们。
这个问题已经表明你根本不需要DTO。您没有受到某些特定业务限制的阻止。您不应该搜索设计模式，以便您可以将其应用于您的项目。你应该寻找真正的问题，以过于复杂/不可维护/重复的代码的形式，以便你可以为它找到一个合适的设计模式。通常，重构重复代码几乎会自动引入新的设计模式，而实际上并未实现它。
一个很好的例子是，当一个JPA实体对于特定目的而言太大时（即实体包含比实际需要更多的属性）。有很多这些部分使用的实体是浪费服务器内存。为了解决这个问题，你可以创建一个DTO类/子类，只根据你创建和填充的一些属性，使用 JPQL中的构造函数表达式
另见：
Assuming that i'm new about the topic DTO.
I can't understand if it is correct to use the DTO in tandem with JSF, Spring and Hibernate.
Let me explain, so far I have used the entity bean, created directly from the database, both in business layer and in the presentation layer.
Now I decided to try using the DTO approach, but I can not understand how they can help.
For example if I have two classes User and Message, and a user has more messages associated; how can I populate the DTO from the database? Or do I manually populate the DTO at the business layer?
can someone post an example on how to use DTO?
Thank you in advance. Regards, Roberto
DTO stands for Data Transfer Object. It's supposed to be a plain vanilla Javabean class without any API/architecture specific restrictions such as JSF, JPA or Spring annotations. I.e. it should not contain any import or FQN pointing to an external API. The sole goal is to be able to pass data between different architectures of a big modular webapplication.
For example, if you don't want to use a JPA/Hibernate entity bean as model property of a JSF managed bean and view because they may not be passed beyond the EJB class due to some overly restrictive business or modularity reasons, then you need to create a copy of this class and map the loose properties yourself. Basically:
UserEntity userEntity = em.find(UserEntity.class, id);
UserDTO userDTO = new UserDTO();
userDTO.setId(userEntity.getId());
userDTO.setName(userEntity.getName());
// ...
return userDTO;
There are plenty of libraries available which makes bean-to-bean mapping easy in following way:
SomeLibary.map(userEntity, userDTO);
However, for the average webapplication you don't need DTOs. You're already using JPA entities. You can just go ahead with using them in your JSF bean/view.
This question alone already indicates that you actually don't need DTOs at all. You are not blocked by some specific business restrictions. You should not then search for design patterns so that you can apply it on your project. You should rather search for real problems in form of overcomplicated/unmaintainable/duplicated code so that you can ask/find a suitable design pattern for it. Usually, refactoring duplicate code almost automatically introduces new design patterns without you actually realizing it.
A good example is when a JPA entity is "too large" for the particular purpose (i.e. the entity contains way much more properties than you actually need). Having a lot of those partially used entities is a waste of server memory. To solve this, you could create a DTO class/subclass based on only a few of its properties which you create and fill using constructor expression in JPQL.
See also:
这篇关于如何在JSF + Spring + Hibernate中使用DTO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
