hello,
I've been looking for something related for a few weeks, but I'm not convinced.
I'm making a RestAPI. And, I know about the DTO.
First, look at the picture above.
The red picture is the part I drew.
Except for the red part, DTO is only mentioned between Controller-Service.
That is, the problem mentions the necessity of using DTO only between Controller-Serve in the example that explains most of the DTO.
But if you dig a little deeper, someone View(Front) - You mention that you need a "separate" DTO used by the Controller.
That means we already need two separate DTOs.
Then next, Now someone says that DTO should be broken down into RequestDTO and ResponseDTO.
Then I have a ControllerRequestDTO that needs to be passed from View to Controller
ServiceRequestDTO that should be passed from Controller to Service
After that, it is transformed into an Entity and after work is done, the returned Entity must be converted into a DTO.
So, ServiceResponseDTO created in Service and passed to Controller
ControllerResponseDTO that should be sent back from Controller to View
I understood that it should be composed of .
But once again, there is very little information about the DTO required by the View-Controller.
ControllerRequestDTO, ControllerResponseDTO, ServiceRequestDTO, ServiceResposeDTO
4 in total.
Am I making it right?
Or are you increasing unnecessary resources?
CodePudding user response：
Software design is not a set of rules to be followed without thinking. Rather, software design is a means to pursue your goals - and different goals may require different means.
So when somebody tells you to create separate DTOs, you should ask (or actually, they should have told you without prompting) why they recommend this, so you can assess whether their goals and circumstances match yours.
Since I am not the person who suggested you create 4 different DTOs, I can only speculate about the goals and circumstances that may have prompted such a recommendation, but I can say with certainty that these goals and circumstances are not universal, and many applications get by just fine with far less DTOs.
Reasons for separate request/response DTOs:
- if fields are read-only, they make sense in the response, but not in a request. Sure, you could simply ignore these fields in the request, but this may surprise the users of your API, and whoever implements the API might accidentally use the field that was intended to be read only. By removing these fields from the request DTO, you remove this ambiguity.
Reasons for same request/response DTOs:
- simplicity
- ease of use (the client can send the DTO he received back to the server)
Reasons for different rest/service DTOs:
- you need to use the same service from different REST controllers, for instance because you have changed the data contract, but need to keep the previous version operational until all API clients have upgraded
- harder to accidentally change the data contract (which would break your API clients)
Reasons for same rest/service DTOs:
- simplicity
As you can see, it depends. But many apps use the same DTO for requests and responses, controllers and services. You should only make additional work for yourself if you see a clear benefit of doing so.
CodePudding user response：
There are many views on this.
For example, controller is seen as mode of interaction between outside world and our application. Therefore, the controller request dto that is received is directly transferred to the service layer ( thus you dont' need service request dto ). Once the service performs all its operations, it returns the service response dto , which the controller directly passes to the end user.
Thus, if you want you can have only 2 dtos - request dto and response dto .
But as I have mentioned, this is one way of designing the application.
CodePudding user response：
In my opinion, it depends on what you need. Let's make some examples.
Scenario 1
You( client) go to the restaurant, you see the menu( view), and you order beefsteak( request DTO). The waiter( controller) takes the order to the cook (services, repository, and he does whatever he needs to make your meal). Then, the waiter comes back with a beefsteak(response DTO) for you.
Scenario 2
You( client) go to the restaurant, you see the menu( view), and you order beefsteak from that restaurant and a burger from Mac Donald's (request DTO 1). The waiter( controller) takes the order to the cook( services, repository), but he also needs to read your order and get the correct item to make an order to Mac Donald's( parse your request DTO 1 and create a new request DTO 2 to call a 3rd party API to get a burger, which should be response DTO 2). Finally, when everything is ready, the waiter brings you the meal which combines the beefsteak from the restaurant and the burger from Mac Donald's (response DTO 1)
And there maybe other cases. But what I mean is it is based on what you need and how you design your system. And I think it should be as simple as possible.
In your image, I think you can use the same DTO (the red one and the black one) if your application is not complicated.