Timeline for Service layer returns DTO to controller but need it to return model for other services
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Apr 20, 2024 at 22:26 | history | suggested | Mehdi Charife | CC BY-SA 4.0 | improved language and punctuation. |
| Apr 17, 2024 at 22:29 | review | Suggested edits | |||
| S Apr 20, 2024 at 22:26 | |||||
| Oct 21, 2022 at 12:28 | comment | added | winson | well, the interface implementation may delegate conversion to a shared component which does the mapping, no? no reason to duplicate code. both components already know about the DTO so why not also be able to invoke its mapper? | |
| Oct 20, 2022 at 22:12 | comment | added | Dalibor Filus | @winson Thank you. But that would mean another mapping/conversion class just for every occurence of this conversion (I have 200+ of them in my app, so 200+ extra classes/beans). | |
| Oct 20, 2022 at 22:11 | comment | added | Dalibor Filus | @BerinLoritsch Thank you. But doing the conversion to DTO like that would mean I'm now converting it to DTO two times, once for AMQP event and once for the Web API response. I need them both for every update/create request. (But it would be fine if the DTOs are different, mine must be the same). | |
| Jun 20, 2022 at 14:20 | comment | added | winson | I want to add that you can hide the conversion to dto behind an interface. Write an interface CustomerUpdateNotifier which accepts the domain object and converts / writes to the queue a dto. the implementation of this interface can be in the layer that is allowed to access/create DTOs. | |
| Mar 28, 2022 at 11:22 | comment | added | Berin Loritsch | That sounds correct. Now as far as whether you need to send the asynchronous event depends on your application needs. If you have a current need to have that notification, then that's exactly what you need to do. If you don't have a current need to notify other services when the Customer information changes, don't build it until you need it. | |
| Mar 27, 2022 at 12:07 | comment | added | Dalibor Filus | So let's say I have a service, which updates the Customer. After the transaction commits, I need to fire an AMQP event that the customer was updated - with the Customer DTO in the message. Because this is a transfer, I need to use DTO in the service. What's your opinion on that? If you think I shouldn't broadcast the event in this service, tell me where else you would do that? | |
| Aug 31, 2021 at 16:37 | comment | added | Berin Loritsch | Yes, a DB entity, if that is what your system is designed around. The only place you need to use a POJO is when you need to serialize and deserialize data through Web API. | |
| Aug 31, 2021 at 16:33 | comment | added | pinkpanther | @BerinLoritsch In your answer Use standard models in your services what is standard model, is it db entity? If not doesn't that inevitably increase the number of pojo types? | |
| Aug 31, 2021 at 16:31 | comment | added | Berin Loritsch | @pinkpanther, I would think really hard before I added that level of complexity. It's important to reduce the likelihood of using the wrong object in the wrong context, or updating one object but not the other. | |
| Aug 31, 2021 at 15:02 | comment | added | pinkpanther | Is it recommended to have 3 kinds of pojos in that case? Else where I also saw people recommending using non entity classes as return types for services. Entities(db related), Service Layer DTOs, and REST(View) layer DTOs which are versioned for each version? | |
| Jan 1, 2020 at 22:36 | comment | added | Imran Javed | If you want to keep services/business logic independent of consumer, then it is always better to have at api level. Idea is to keep dto convertion at edge. | |
| Nov 19, 2019 at 12:03 | vote | accept | Youans | ||
| Nov 13, 2019 at 19:42 | history | edited | Berin Loritsch | CC BY-SA 4.0 | added 393 characters in body |
| Nov 13, 2019 at 17:06 | comment | added | tom van green | Ah, I think I get your point now ;) Do I understand you correctly that you are saying the service should not return a dto and that it should be the controllers responsibility to convert it to a dto? If so you could maybe update your answer to make this more clear, as I completely missed this point and thought you are discouraging OP to use dtos at all. Edit: Hmm, I can't change the downvote until you edit your answer... | |
| Nov 13, 2019 at 15:23 | comment | added | Berin Loritsch | The best practice is to not use DTOs in your service layer. Only use them at the edges. Without DTOs in the service layer, there is no conflict for what the OP wants. Or am I missing something? | |
| Nov 13, 2019 at 14:17 | comment | added | tom van green | While your point is very valid, I think it does not answer the question. | |
| Nov 12, 2019 at 15:13 | history | answered | Berin Loritsch | CC BY-SA 4.0 |