AutoMapper How To Map Object A To Object B Differently Depending On Context

Question

Calling all AutoMapper gurus!

I'd like to be able to map object A to object B differently depending on context at runtime. In particular, I'd like to ignore certain properties in one mapping case, and have all properties mapped in another case.

What I'm experiencing is that Mapper.CreateMap can be called successfully in the different mapping cases however, once CreateMap is called, the map for a particular pair of types is set and is not subsequently changed by succeeding CreateMap calls which might describe the mapping differently.

I found a blog post which advocates Mapper.Reset() to get round the problem, however, the static nature of the Mapper class means that it is only a matter of time before a collision and crash occur.

Is there a way to do this?

What I think I need is to call Mapper.CreateMap once per appdomain, and later, be able to call Mapper.Map with hints about which properties should be included / excluded.

Right now, I'm thinking about changing the source code by writing a non-static mapping class that holds the mapping config instance based. Poor performance, but thread safe.

What are my options. What can be done? Automapper seems so promising.

Answer 1

The Mapper class is merely a thin wrapper on top of a Configuration and MappingEngine objects. You can create separate instances of Configuration/MappingEngine objects (still using singletons), and use your IoC container of choice to load the correct one as necessary.

The best option still is to use different destination types. The really tough part about truly supporting this feature is the inherent hierarchical nature of type maps. The top-level object might have a mapping profile, while lower level ones do not. Some in between might have it or not, etc.

Answer 2

To me, it sounds like a better design might be to have multiple destination classes (possibly inheriting from a common base or implementing a common interface)

If the unmapped properties will never be used in one of the variations, you could leave them out entirely (giving compile time guarantee that they aren't used by mistake), throw an exception when they are accessed (not as good as a compile time guarantee, but sometimes you need the full interface to be implemented) or even use a substitute value.

For example:

public class Source
{
    public string Name {get;set;}
    public BigEntity {get;set;}

    /* other members */
}

public class SourceDTO
{
    public string Name {get;set;}
    public BigEntity {get;set;}
}

public class SourceSummaryDTO
{
    public string Name {get;set;}
}

Alternatively, you could do this:

public class SourceSummaryDTO : SourceDTO
{
    public string Name {get;set;}
    public BigEntity 
    {
        get{throw new NotSupportedException();}
        set{throw new NotSupportedException();}
    }
}

That way, you could pass a SourceSummaryDTO as if it was a SourceDTO.

Having properties conditionally populated sounds like a recipe for trouble to me - I'd rather have classes that are explicit about what they contain, especially with Data Transfer objects.

For me, the best thing about Automapper is the ability to verify the mappings and then know that every property on destination classes will be populated.