Question

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 ?

Answer 1

My two biggest arguments for Automapper:

1. 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.

1. 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.