java - How to use DTO in JSF + Spring + Hibernate

Question

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

Answer 1

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:

• DAO and JDBC relation?
• JSF Controller, Service and DAO
• JSF Service Layer