❔ Need Experience Sharing
If we works with a solution that contains multiple projects (lets say following the DDD clean architecture),
Where I have the followig projects:
Core (Contains only the core entities and Interfaces)
EFCore (Contains the EF Core)
CQRSCore (Contains the CQRS implementation)
WEB (Is an ASP.NET Core api)
From your experience:
Is the
CQRSCore queries should return the pure entities of the Core project or should it returns DTOs ?
What is the best place to put the Automapper and using it ? (means which project of them should use the automapper)
And thanks in advance.13 Replies
CQRSCore being the service layer should return DTOs, not entities.
I'd put auto mapper in CQRSCore. I'll note down however that I've seen a lot of people discourage it and recommend doing the mapping manually. I believe the justification was because its black magic. You are unaware of what it does underneath and can cause problems in the future.
Another thing that has been pointed out to me is that you should have another set of DTOs in Web API project. The reason being is that Web Api endpoints shouldn't change so you don't break consumers of the web api. If you change a service layer dto it will also change the web api endpoint(for example if you remove some property from the service layer dto).
Another reason is, If all of your endpoint parameters don't come from body, you will need a separate dto for the from body parameter which then inside your endpoint method you would combine the data from the query parameters and the from body dto parameter to a service layer dto.
One more thing I've learned is to always use a DTO for your FromBody parameter. If you use a single value type then the web api request body would be just the value for example int
1, while if you store that int as a property inside a dto and use that dto as a from body parameter, the request body would look like { "MyIntegerPropertyName": 1 }. This would allow you to add additional from body parameters if you ever need them in the future and it won't break any existing consumers of your endpoint. It also adds consistency between your web api endpoint request bodies.
If you have any questions about any of this feel free to ask@Pendramon First of, I want to thank you so much for your time and effort to share your experience I really appreciate,
Everything clear, but about the
API should it contain another DTO instead of the DTO that CQRS uses ?From my recently learned experience, yes. I hate having so many layers of DTOs but unfortunately it seems like it has to be done.
Alright, I think that too, at least will provides some separation
So, the
API should not deal with the pure Entities that CQRS and EF Core deal with?No, specifically because Entities may contain some data that the Web API should not know about.
Or perhaps you do some manipulation of that data in the service layer and need to show a different result to the web api.
Alright, its very clear
There is this idea that Service layer should be agnostic to the top level project using it. So if you were to use a console app for example instead of a web api, it should respond the same way to the same requests.
The bad thing about this is that you then automatically can't use most of the WebAPI niceties like filters, middleware, etc.
But how far deep you should go depends on the size of your application.
Its like a scale, on one part is design patterns on the other part is the size of your application. There is no point in doing all this if your application just does 2-3 simple data operations.
Yeah
Very clear explanation, I really appreciate so much
If I have any other experience share, it is ok to contacting you ?
Of course!
I too have a lot to learn. I just scrapped my whole project cause of bad database modeling and some of the things I posted here 😄
great, massive thanks
XD, me too, all we did those mistakes, but we should keep learning
The learning path never ends, but we get closer and closer each time
Yeah, but sometimes boooooooooom a new feature released and you have to look at it 😁
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.