Why do experienced devs hate Automapper and prefer Riok Mapperly
I have noticed that experienced developers prefer using Riok Mapperly, rather than Automapper. Why?
16 Replies
Automapper doesn’t provide any validation of your mappings until runtime
So stuff can blow up unexpectedly
You can write unit tests to validate the profiles you’ve made but eh
I think since it is reflection based mapperly which is source gen based may be more performant, but I haven’t seen the latest benchmarks so don’t quote me on that
Okay, I heard it was difficult to debug
So can Riok Mapperly do everything Automapper can do?
I don’t know about everything since I don’t know everything automapper can do
because its a nightmare to debug issues, its hard to breakpoint, it hides things away, it makes u lose time that would have been better spent if u had done thing manually or with a better mapper.
Okay. That makes sense
Do you know other mapper alternatives apart from Mapperly
currently I've been dueling between a vs extension called MappingGenerator and Mapperly
Mapperly lacks some features u need to implement ur self such as recursion for example...
Okay, alright
which is one of the points, automapper can do a lot of stuff, and this can backfire if misused, because logic shouldnt be in the profiles
As someone who never used automapper and recently starting working on a code base, where it was used. I started hating it real quick.
You don't know what's happening and the only way to find out is a lot of searching in the code base.
While mapperly or even hand written mappers, you can just navigate to the code and read it.
I've never felt a need to use any framework to perform mappings.
Expression<Func<TFrom, TTo>> has always been very much sufficient to do the job.
Frameworks at a bunch of bloat and extra stuff to maintain, it's yet another bit of busywork.
They also tend to only work in good scenarios and are useless anyways when things get complicated.
Also anything that "automatically" maps fields is an antipattern imo, mapping should be opt in, not opt out. Do you really wanna be trusting a 3rd party framework not to fuck up and potentially expose stuff you didn't want exposed?
Finally automatic mapping obfuscates a devs ability to check, for a given field "where are all the spots this thing gets used".
If it's automapped to something else there's zero code indicating this. They could see a field that says "zero uses" according to the LSP, delete it, and suddenly stuff breaks even though checking with Roslyn "where dies thus get referenced?" Returns zero results
Rule of thumb:
Try hard to not fall into the antipattern of abstracting your code into too many layers and installing a bunch of libraries to solve all your problems.
Most of the time the long term best path is just write the dang code and stop trying to find shortcuts 😉Very true. Thank you for this
it's the same as
So stuff can blow up unexpectedlybecause if you want to reference explicitly every field you have to use .ForMember(), but at that point probably you could just go with handwritten mapping anyway
You don't know what's happening and the only way to find out is a lot of searching in the code base.yeah but this is common in all code bases, and especially in modern ones where with a fluent .UseSomething() you can add an indefinite amount of modules/packages/whatever
Yes, just do the mappings by hand explicitly, its substantially less prone to failure, less prone to bugs, its truly easier to maintain, doesnt require onboarding on yet another tool for new devs to use, doesnt use reflection, and is by far way better for performance.
The list goes on and on and on, just do the mappings by hand so behavior is explicit, in the long term I strongly recommend this as it truly is easier.
"But what if I have to map 200 fields? I have to write that by hand?" I hear you ask.
Easy, learn to use
sed and grep and you'll suddenly find a lot of common dev issues vaporize very fast as you learn how to write code 100s of times faster than you ever thought possibleTo be fair the reflection problem is not a problem with a source generated mapper.
GitHub
GitHub - MapsterMapper/Mapster: A fast, fun and stimulating object ...
A fast, fun and stimulating object to object Mapper - MapsterMapper/Mapster
Source generated is slightly better but all the other issues are still present. Mappings should be explicit imo.