Java – spring MVC: should the service layer return dto specific operations?

In my spring MVC application, I use dto in the presentation layer to encapsulate the domain model in the service layer Dto is used as a backing object in the form of spring

So my service looks like this:

userService.storeUser(NewUserRequestDTO req);

The service layer will translate dto – > domain objects and complete the rest of the work

Now my problem is that when I want to retrieve dto from the service to perform update or display, I can't seem to find a better way to perform it, and then there are multiple methods to find and return different DTOs, similar

EditUserRequestDTO userService.loadUserForEdit(int id);

DisplayUserDTO userService.loadUserForDisplay(int id);

But there is something wrong with this method Perhaps the service should not return something like edituserrequestdto, and the controller should be responsible for assembling requestdto from a dedicated form object, and vice versa

The reason why there is a separate dto is that the strong type of displayuserdto is read-only, and many user attributes are entities (such as city and state) in the lookup table in dB. Therefore, displayuserdto will have the description of this string Property, and edituserrequestdto will have an ID that will support the selection drop-down list in the form

What's your opinion?

thank you

Solution

I like the compact display object It is more efficient than building an entire domain object just to display a few of its fields I used a similar pattern, but a little different I only use the domain objects in the view, not the edited version of dto It significantly reduces the work of copying data back and forth between objects I haven't decided whether to do this yet, because I'm using JPA and bean validation framework annotations, and mixed annotations look confusing But I don't like using dto just to keep domain objects outside the MVC layer It seems that many jobs don't have much benefit In addition, it may be helpful to read Fowler's views on anemic objects It may not be fully applicable, but it is worth considering

First editor: reply to the following comments

Yes, I like to use actual domain objects for all pages of a single object at once: edit, view, create, etc

You said you were getting an existing object and copying the required fields into the dto, and then passing the dto as part of the model to the template engine of the view page (and vice versa, for creation) What will this bring you? The weight of the reference to dto is not less than the weight of ref to the complete domain object, and you need to copy all additional attributes There is no rule that your template engine must use every method on an object

I will use a small part of the domain object if it improves efficiency (no diagram is established), especially for search results However, if an object already exists, don't worry about its size or complexity when you paste it into the model to render the page It does not move objects in memory It will not cause pressure on the template engine It simply accesses the methods it needs and ignores the rest

Second Edition: good idea In some cases, you may want a limited set of properties available to the view (that is, different front-end and back-end developers) I should read it carefully before answering If I'm going to do what you want, I might put separate methods on the users (or any class) of forms foredit () and fordisplay () In this way, you can get users from the service layer and tell users to use their own limited copies I think maybe that's what I've achieved with anemia object review