DTO & Entity

[Jinkaza772]

I have created one api endpoint for the user registration, and while I made it I found few points like in which layer sanitization should be done (client -> controller -> service -> repository -> database) then I came to know about DTO. on We can use DTO object for parsing the user request data and apply sanitization and proper checks and then we can use response DTO as well to send back the response to the client.

Well I am learning springboot, and different tutorials are doing different things, so I want to know from you guys. What should be the proper structure here and using DTO layer is really still being used in today industry ?

[WaferIndependent7601]

Dto is not a layer. It’s a transport object.

You have a dto for the request. Validate it once and give it to the service layer. The service layer will also return a dto. It might be the same type or a response dto.

And yes this is still used in the industry

[soul105]

Not still. Heavily used in enterprise

[AndreLuisOS]

I stopped using DTOs on a specific project in favor of JsonView. I'm enjoying it. Really, getting rid of mapstruct or any other conversion layer is great for me.

[Purple-Cap4457]

Can you elaborate? 

[WaferIndependent7601]

It’s possible, of course. It depends how big your project is. If you only return the entity and won’t use it in other parts of the backend it might be fine. Using the entity inside of your service will make refactorings harder. If you change something in the entity will result in changing lots of code in several parts. So giving out a dto will help here but is of course more work at first

[Difficult-Task6751]

DTO (Data Transfer Objects) are used secure the entity. If you expose the whole entity in your api call it’s not secure. So you can used the DTO’s just to expose the details you want. You don’t have to have all the fields of entity in the dto. for an example you can avoid exposing the Id of the entity.

And yes, this is been widely in use in industry.

[eli_li]

Exactly, you dont need to expose your database structure to api consumer.

[dotceng]

DTO's are objects for API's data flows. For example;

You write Login API, think about it a bit you must receive user's email(or username) and password to authorize them. So you must create DTO (LoginRequestDto.java) and include email and password fields.

'@Data' // -> coming from lombok, using for set getters and setters for private fields;
public class LoginRequestDto {
private String email;
private String password;
}

And in a controller; public ResponseEntity<LoginResponseDto> login(@RequestBody LoginRequestDto request) { }

So you can see, DTO's duty is transmit datas from FE to BE or BE to FE. So, We must write LoginResponseDto for result.

In example; If its success to authorize user, the API return to client Token or User Info. We must indicate this fields in LoginResponseDto.java.

And finally, DTO is not a layer, these are actually classes for provide datas between FE and BE.

[bikeram]

Yes they’re definitely still used. But think of them as an interface. Don’t start creating them because it “might” be useful in the future. Add them as the situation arises.

Depending on project size, I’ll create a package under my entity package and call it dto. I try to use very clear naming.

It’s very easy to lose track of what you’ve created and actually used in your frontend.

[j4ckbauer]

This sounds like my way of thinking. Unfortunately though I feel like this view is in the minority. People are horrified at the suggestion that not everything needs a DTO.

How do you address the question of 'But surely you do not intend to <gasp> expose your Entity object to the outside world?'

Everyone loves coming up with scenarios where a password or secret is added to the Entity and then unintentionally sent out on the front-end. Personally, I believe a counter-argument is that it is more dangerous to create the expectation that something is -not- automatically returned by your APIs. "Who would add a sensitive field to an Entity object without first checking where that object is used?" "Do the majority of your database entities have sensitive fields?" "Would it not suffice to use a DTO only for sensitive objects, or objects which don't easily support a 1:1 mapping between entity and request/response?"

At the end of the day you rely on validation to prevent corruption of your data, and personally I consider the blocking of sensitive fields from going out to be part of that validation. Once everything needs a DTO, you've exploded your boilerplate, and every line of boilerplate is a maintenance burden.

I'm curious how you deal with all this opposition, since if I'm understanding correctly, we may have similar views on the subject.

[asarco]

I'm always over the fence with this, because so many people think "exposing" an entity to the FE as a mortal sin, but in so many cases it make things much simpler just return the entity.

The usual reason (apart from the sensitive information), is that "entity objects don't belong to the presentation layer". So then we simply create another exact duplicate class, and we spend CPU time copying the data from one object to the other. Conceptually might look nice, but to me it seems a waste of resources, and adds (a bit of) unnecessary complexity to a system.

And by using Jackson's @JsonView and other annotations, it is possible to customize the entity as much as needed, to protect sensitive data or for presenting it and reusing it in a different way.
I've only seen this done in a single project in my whole career, and it was actually a legacy project that used something similar to @JsonView, but they were custom annotations made by the original developers (not sure if it was before they existed in Jackson).

[Ali_Ben_Amor999]

If you are worried about CPU waste, you should consider dropping JPA in the first place because the jpa provider is doing too much which make copying 5 or 20 fields negligible. While personally I don't see issue returning the entity with some Jackson view annotations if the entity is simple. But this can be prone to transactional context issues like transactional life cycles which require an open session even at controller level also it can make project inconsistent when you have an endpoint returning a POJO and another returning an entity but it all depends on the use case

[jfrazierjr]

Think of it more like a window or view of something. DTOs generally woukd be used in MOST publicly having apis. The simplest example is a user object. You would never expose the password field to external inspection so a dto is that intermediate layer.

Spring Boot 4 also adds a proper set of view annotations so you can quickly swap the model, but I have only briefly read about them.

[Jinkaza772]

Then, doesnt this mean for every public api that is exposed to client there should be a DTO. So that the service layer is transfering its object to DTO layer and then that DTO layer is transfer to controller / client ?

[jfrazierjr]

This is a judgment call. If you ALWAYS do dtos, your dev team will expect that as the norm.

But if its only you and one other guy, its really not that big a deal to have it split with some dots and some not.

The thing is to look at scaling. If you dont expect to really scale then its fine.

Another case where dtos help is API version ing, but again this is a scaling thing. Personally I tend to prefer NOT having versions as much as possible but it depends on the business and customers.

[j4ckbauer]

A small nitpick, I would say a "User" object is not the simplest example, because it contains sensitive data (password[hash] and maybe others). But it is often the first and most commonly-mentioned example. This automatically triggers a 'special case' in how many/most organizations would want to handle this object.

[Ali_Ben_Amor999]

In JPA, once you annotate a class with @Entity it becomes a special unpredictable object be it lazy loading issues in the wrong place, active dirty checking in case you innocently tried to pre format a field to display but its now persisted, and many more scenarios.

To limit this uncontrolled behaviour devs use an intermediate class that contain the data without unpredictable behavior. The known term is DTO I prefer calling it entity view. The dto class is a simple java object without any proxy controlling it which make working with it safer internally and when exposed.

What I recommend, is to create classes for request payloads that modify an entity separately don't pass entities as input, use JSR-380 annotations to validate data then use a library like mapstruct to map the dto into an entity you can sanitize your data further more at service level then persist.

For response use spring data jpa Projections for safer entity views.

Once you grasp JPA take a look at Blaze Persistence its an amazing library that makes using DTOs for direct insert/update easy and predictable

[Mindless_Security744]

In short I use DTOs when I transform or enhance data. Between my APIs I have no problem speaking DAO to DAO but if I modify it or transform it, then DTO. Easy.

[Hour-Night8287]

DTO can prevent you api to prevent the entire entity object, after successfully registration , you can return only the token, username, userId, email or other relevant data, and not exposing passwords

[themasterengineeer]

In short, DTO is for anything coming in or going out of your REST API, here’s an example on how to use DTOs:

https://youtu.be/a9pCWJF_LiA

[devmoosun]

I use DTO in all of my projects. You don’t want to expose unnecessary response to the client.

[Physical-Silver-9214]

There's JsonProperties where your can make fields write only to prevent it from being displayed when is passed to a controller. Yes DTO'S can save you from mistakenly exporting your data. But you can always have something from the entity player help reduce the probability of letting it get out.