问题
I want to start using AutoMapper at our firm. The problem the my team members just don’t see any benefit with it. The main claim why we need addition abstraction when we can write our-self extensions method that doing the same.
So what are the reasons I can raise against ?
回答1:
My two biggest arguments for Automapper:
- Why write something custom when you can rely on a well-tested, convention-based library to do for you?
Yes, you can write extension methods to move data between properties. But, why would I write countless mapping lines just for shipping data across types, e.g.
Property1 = original.Property1; Property2 = original.Property2;especially when you are doing thing like this:
Property1 = (MyEnum)Enum.Parse(typeof(MyEnum), original.Property1);It's messy plumbing code that is time-consuming to write, and you have better things to do with your time, like building useful features, to mess around with things like this. AutoMapper provides all the convention you need to get the first case done for free, and simple patterns for managing the more complex scenarios where you are reducing shapes or changing types.
- The maps themselves are easily testable.
Again, you can write your own methods. However, if you're doing things correctly, you have corresponding tests to cover all the cases inherent with the custom code you just wrote. Or, you could just loads your maps up and ask AutoMapper if your mapping configurations are correct.
My caveat argument against Automapper:
- If you start having to write enough exceptions to the map that you have pretty much stopped relying on configuration, it's likely become a leaky abstraction. (In actuality, the problem probably lies in the design of your domain and AutoMapper is just the first constraint that signals the upstream problem).
I'm not saying it's the panacea for mapping code (it has its quirks) but the time expended spiking with it to see if it fits your solution is worth the investment.
回答2:
AutoMapper is useful when you have a lot of code that does nothing but map one type to another.
Ask yourself this. What will cost less time to develop and maintain: Hardcoded mapping or setting up a framework like AutoMapper?
The following subjects can help you decide whether an auto mapping framework is useful for your scenario:
- Bulk. How many lines of code will be dedicated to mapping? How many entities need to be mapped? 10? 100? 1000? The more lines of code, the more you will benefit from this framework
- Complexity. How complex will your mapping be? Is it all basic one-to-one mapping? Do objects need to be expanded or flattened? For complex scenario's, you will most likely be limited by an auto mapping framework.
- Non-mapping. Is your current mapping code actually 100% dedicated to mapping objects? Does it do anything else like parse data or check business rules? The more responsibilities your mapping code has, the less useful an auto mapping framework will be.
回答3:
A common challenge with a transactional app (lots of CrUD operations against a 3NF database) is you often have to map a 3NF database to an object model (i.e., business objects/classes), and then again to the presentation layer. The database stores data as tuples (row & column), data is often displayed in the app as tuples (i.e., a grid), but the object model is a graph - it's like going from 2-dimensions (db) to 3 (business logic) back to 2 (presented as grid). ORM mappers help translate 3NF to objects, but flattening out objects for representation on the user's screen requires creating presentation-specific classes.
Automapper is great for mapping from one type (business object) to another (data transfer object) in scenarios like this, as well as many others
来源：https://stackoverflow.com/questions/11510061/reasons-using-automapper