Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What are the disadvantages of using auto mapper libraries?
I have noticed that lots of projects (both in real-world and within online courses) use Automapper to map domain models to view models, API models.
The main advantage seems to be convenience by removing the need for lots of assignments when dealing with models with lots of properties.
However, almost always any convenience comes with a cost. What are the main disadvantages of using auto mapper libraries?
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Based on my experience auto-mapping has some drawbacks:
-
"find all references" not working as expected - anyone relying on the "find all references" functionality or similar will miss the implicit assignments happening only at runtime due to automapping
-
property rename - if any of the properties is being renamed, depending on the configuration, the mapping no longer happens leads to an exception at runtime. Explicit assignments are not affected by such a refactoring
0 comment threads
-
It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with.
-
Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
// Conditional assignment in AutoMapper.
var configuration = new MapperConfiguration(cfg => {
cfg.CreateMap<Foo,Bar>()
.ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
});
// Same thing in a function.
public Bar FooToBar(Foo foo) {
// So many boring but readable bar.baz = foo.baz type statements.
bar.baz = (foo.baz >= 0) ? foo.baz : 0;
}
-
I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.
-
Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.
0 comment threads