Should I consider using DTO for Spring Rest Controller layers instead of Entities?

Question

I have started a Spring Rest project as a beginner. Most of my entities have more than 15-20 attributes and not all attributes are required on the UI layer.

I am considering using DTO for the following reasons:

1. To minimise the un-necessary information to be sent for information privacy reasons.
2. To reduce the size of the json string for performance.
3. Different UI using the same entity may have different business validations (i.e. mandatory/optional fields). I can create 2 DTO for the same entity and annotate the validations accordingly.

I am considering using DTO to merge multiple entities together, hide/show certain information for certain UI based on the roles, but I have to "split/copy" the DTO information back to different entities when I need to persist the details.

Staff - Able to view the performance appraisal and comments by the next level manager. Manager - Able to enter comments for the performance appraisal, and indicate the pay increment for the staff (This is not shown in the staff's UI), but not able to view the staff's current pay. HR - Able to view all the details for all UI.

I would like to find out if there is a better way to handle such concerns or am I heading the right direction for my project?

Ref: http://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application

Answer 1

It's better to use the DTO to have a clean architecture, with DTO, when you modify the Table, nothing will be changed for the FrontEnd.

BUT it's better to use it carefully.

1. The DTO is not free, you should pay for the maintenability, the code lines(more codes, more bugs), you should have an idea about the ROI.
2. If you have more than 5 developpers, and you work for a big project, yes you can.
3. For a new From Scratch project, don't start with DTO, it's too heavy, at first, make your application run, focus on the business layer, not the controller or presentation.
4. You don't need to create DTO for each entity, juste create you need, in fact, you can always resolve the problem by using JsonView or creating a new API, which is better for the maintainance.
5. Instead of DTO, you can use JsonView, JsonIgnore to custom the response, it works great for the small/medium projets.
6. Use a mapper library, i suggest modelMapper for simple project, Orika for Complex project, Attention, Lombok is not compatible with these mapper libraries

Good luck.

Answer 2

I always use DTOs to decouple my views from my JPA entities. In addition to the 3 reasons you list I can add the following.

• JPA often have two-way references between parent and child, one of them is real (exist in the DB) the other is synthetic. When serializing to JSON you only have the parent-child relation, which is the synthetic one.
• If you deserialize directly to an Entity, you have to have a complete understanding of detached entities, and merging. If you have ever tried to merge large cyclic entity graphs, you will know this is not a walk in the park.
• For JSON views performance can also be important. If you use the entity for JSON generation, you have to load all columns. It is often more efficient to use a projection, and select the columns you need directly into a DTO.
• If you have an API, you can put the DTO into a separate module that can be reused as a dependency by others, and you never want to do that with entity classes.
• Immutability was mentioned by JB Nizet, which is also a good point. using @JSONCreator you can have immutable DTO, which can have some advantages - although most times DTOs are not used in a multi threaded context, and therefore not needed.

In My projects I always use Lombok to generate access method, which means that DTOs usually only contain the data field (sometimes input DTO has validator or utility method). This makes them super easy to create/modify, and easy to distinguish from classes that contain logic. Creating the DTOs takes no time compared to writing the business logic, so there is very little cost of having this decoupling, and I honestly believe it makes it easier to read the code.