❔ How to organise mappers
Hi !
As our app grows, we're confronted to mapping problems
We are using two main mapping methodology for dto and entities
Either we create a profile for automapper concerned with a specific entity or extension methods
say, we have
- EntityFoo
- FooDTO
- FooPostDTO
- FooProfile
with both configuration for EntityFoo <-> FooDTO
and EntityFoo <-> FooPostDTO
- FooExtension
with several extensions method "Map" with various arguments. The likes of
EntityFoo Map(this EntityFoo entity, FooDTO dto);
EntityFoo Map(this EntityFoo entity, FooPostDTO dto);
Called in the code like so var entity = new EntityFoo().Map(dto);
We want to add the field bar to Foo
FooPostDTO get updated with bar
EntityFoo also
But then, we try and use the extension method.
No error thrown, but the field is not set.
So, this looks like something that shouldn't be done?🤔
But what about automapper?
The automapper maps correctly the bar field since it's present on both side for EntityFoo and FooPostDTO
But the same thing happens when using automapper for FooDTO
It's not updated with the new field, but it won't throw since all assignable field is present on EntityFoo
We'll potentially never know that it's not working like intented...
So... Looks like it shouldn't be done like this either?🤔
Is there a way to prevent that at coding time ?
With compile time error so we CAN NOT make the mistake (rather than letting it pass through and blow up in our face later on)
I've been messing a bit with records.
Declaring them and their field solely through their constructor
Thus, if we update the record, we add the field in the sole constructor of the record
It then won't work anywhere if the call isn't updated
This looks like a sound idea !
Though, I've been thinking...
Why even use a record?
Defining specific ctor should do the trick anyway
And... "Mapping" through ctor wouldn't have cause all the trouble I explained in this post...
So, I was curious. How do you manage mapping on your side? 🤔5 Replies
We don't use any sort of mapper at all, my dtos take the entities in their constructors. It'svthe same amount of work without the extra dependency
Plus it's intentional and obvious what's being done.
thank for the input, toddlahakbar 🙂
May I ask about the relative scope of those projects? 🤔
There are also some source-generated compile time alternatives available for mapping by now I think, so you would get around the potential issue of only finding mapping issues at runtime through exceptions. I don't really know which ones since I usually write mapping code by hand, but you might find something
Could be an option as well
@Alta the projects are complex investment management line-of-business applications
Our largest json payloads run between 40 and 75 MB (which is larger than our entire compiled app and all its dependencies to give you some context on complexity
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.