✅ Theoretical question. MediatR and DTO and onion structure
Hello,
THe following is just theoretical and I do not need any code
In the programming world, transferring the received object from the api to other parts of the programm for processing is seen as bad practise.
Keeping this in mind, then we should map the received data (could use automapper).
However if I use the onion structure in combination with Mediatr, there is a mapping done automaticly. The reason why I think this is because MediatR (if I'm correct) uses reflection and generic types. This means that there already is a mapping (indirect).
Now I think about using this structure without the mappings.
ps. If I would use n-tier structure the mapping would go to the same properties in the object only from the contract to the dto.
My question what are you're thoughts on this.
10 Replies
mediatr does not do mapping
There is no mapping in MediatR. It's just pipelining requests to handlers, or whatever terminology you want to call it. It covers CQRS which I think is what you're referring to here.
As far as the mapping goes, I tend to steer away from AutoMapper as it's putting a lot of trust in something which is convention based.
That's just my opinion though. As long as your API doesn't know about your domain, and your mediatr just sits between and mediates things, mapping is a different concern. Your CQRS layer is fine to know about your domain objects so you can map in those handlers no problem
i just map to/from DTOs by hand
i wouldn't use any complicated architecture either unless the project really called for it
$vsa is plenty for lots of projects
That's what I've been doing for a while. AutoMapper is reflection convention based which is really popular. I just don't like the black box nature of it. I feel more comfortable seeing all my mappings explicitly. Not so familiar with all these new terminologies, I'm guessing it's a bit like clean architecture which I've seen and used to some degree myself. I never really force an architectural pattern to projects, it tends to just come out naturally. My domain is always at the very bottom with no dependencies above. I don't really do all the database adapter stuff bob martin harps on about
I'll have support for EF core writing and dapper reads in a separate layer, a layer for services, then the CQRS layer which may or may not even use the services, then the API
yeah my current project is basically EF models, services, and feature folders
yeah sounds like a good start, as it grows, you can create more layers
yeah, no point in overcomplicating it right out of the gate
bang on! if you're aware of architecture, you'll notice and adapt it over time
thanks for youre thoughts.