Object-object Mapping - Why I don't use Automapper

a.md

Object-object Mapping - Why I don't use Automapper

At the boundaries of an application it is often nice to map objects from one form to another. The most common example is mapping domain entities to view models, or mapping to dtos for network transfer.

Automapper is a library for removing the duplication from object-object mapping code by mapping by convention. When the conventions don't map the way you want you can explicitly map properties.

After using AutoMapper on a couple of projects I have stopped using it. The problem is that the convention based mappings introduce annoying bugs when property names change or the object graph changes. When a change breaks the convention it results in a runtime exception. Very annoying.

What I Do Instead

z

My observations from using automapper are:

1. If you use the convention-based mapping and a property is later renamed that becomes a runtime error and a common source of annoying bugs. 
2. If you don't use convention-based mapping (ie you explicitly map each property) then you are just using automapper to do your projection, which is unnecessary complexity.

For larger projects I like to implement explicit type mappers and register them in an IoC container. The advantages are:
mappers are explicit. Easy to identify and test mappings
the mappers can have their own dependencies. The consumers of the mappers don't have to depend on the mappers dependencies.

=======================================================================================================================================


public interface IMapper<T1,T2> 
{
    T2 Map(T1 input);
}

public class MapAppleToOrange : IMapper<Apple, Orange> 
{
   public MapAppleToOrange(/* opportunity for constructor injection here. Useful for mapping VMs -> persisted models */ ISomeDependency dependency) 
   {} 
   
   Orange Map(Apple input) 
   {
       // map things here
       // make use of dependency
   }
}

// usage

public class HomeController
{
    // let the IoC container resolve the required mappers
    // note that HomeController does not depend on ISomeDependency 
    public HomeController(IMapper<Apple, Orange> mapper) 
    {}

    public ActionResult Index(Apple apple) 
    {
       // do some mapping
       return View(mapper.Map(apple));
    }
}

AutoMapper has a validation feature that you can place in your test project. You execute it using Mapper.AssertConfigurationIsValid(). This will provide a useful warning if, for any destination property, there is no matching source property (and no explicit map).

It's been a couple of years since you posted this, and the points are valid. However, after I discovered AutoMapper, I called for a refactoring from statically based configurations to isolated configurations. Reason? I don't want to incur the overhead of my ENTIRE ecosystem for a single controller's responsibilities. When I do want a mapping, what I end up with are very problem specific set of, almost always, controller based mapping configurations. This works famously well at least for my purposes.

You can use my MappingGenerator VisualStudio extension to generate implementation of your mapping methods in design time. Project is available on github https://github.com/cezarypiatek/MappingGenerator and the extension can be downloaded from Visual Studio Marketplace https://marketplace.visualstudio.com/items?itemName=54748ff9-45fc-43c2-8ec5-cf7912bc3b84.mappinggenerator