Automapper together with Dependency Injection

Question

I currently have the following mapping:

Mapper.CreateMap<Journal, JournalDto>();

Now, Journal contains a member named RefTypeID, which corresponding value exists in another table in the database; to look up this value, I have a service which handles a simple int -> string request. The automapper configuration currently happens in a static class at the start of the program. Is it okay to move the mapping code into a class which gets injected into my DI container or is there a better way?

The only reason I can think not to would be purely organizational. You'll potentially have mapping code all over your project(s). If your domain object changes or dtos might be less than ideal. But I'm curious to find out from other people their opinions. — Daniel, Nov 17 '10 at 14:08
Well, I would still keep the mapping code in one place - ie. that class, which would grab all needed services from the DI container. I just have to initialize the mapping myself instead of being able to rely on the static constructor executing it automatically. — Femaref, Nov 17 '10 at 14:15
For the latest version, take a look at [this](http://stackoverflow.com/a/35431096/1977871) so answer — VivekDev, Aug 08 '16 at 11:53

score 19 · Answer 1 · edited Nov 13 '13 at 17:52

A better way is to use a customer resolver. Mapping configuration is intended to be static, so custom resolvers are intended to provide mapping for a single member:

Mapper.Initialize(cfg => {
    cfg.ConstructServicesUsing(type => WhateverMefUsesToGetInstances.GetInstance(type));

    cfg.CreateMap<Journal, DisplayJournal>()
        .ForMember(dest => dest.RefTypeName, 
            opt => opt.ResolveUsing<RefTypeNameResolver>());
});

Then your resolver becomes:

[Export(typeof(IRefTypeNameResolver))]
public class RefTypeNameResolver : ValueResolver<Journal, string>, IRefTypeNameResolver
{
    private readonly IRefTypesLookup iRefTypesLookup;

    [ImportingConstructor]
    public RefTypeNameResolver (IRefTypesLookup rtl)
    {
        iRefTypesLookup = rtl;
    }

    protected override string ResolveCore(Journal source)
    {
        return iRefTypesLookup.Lookup(source.RefTypeID);
    }
}

Configuration needs to execute once, which is why the configuration API provides hooks into the execution API (type converters, value resolvers etc.)

I knew about the ValueResolver, but I thought they were useless because I was missing the ConstructServicesUsing configuration. Nice one! — Kugel, Mar 20 '13 at 13:15

score 14 · Answer 2 · answered Dec 12 '11 at 15:23

14

You could take a dependency on IMappingEngine instead of using the static class Mapper.

There's a nice blog post about it here: Mocking out AutoMapper with Dependency Injection

answered Dec 12 '11 at 15:23

Martin R-L

4,039
3
28
28

score 9 · Accepted Answer · answered Nov 18 '10 at 00:41

Here is how I solved it:

I defined an IMappingCreator interface:

public interface IMappingCreator
{
  void CreateMappings();
}

I went ahead and implemented a class with that interface (I'm using MEF as DI container, that's where the attributes are comming from) which is put into the DI container as IMappingCreator:

[Export(typeof(IMappingCreator))]
    public class Mapping : IMappingCreator
    {
        private readonly IRefTypesLookup iRefTypesLookup;


        [ImportingConstructor]
        public Mapping(IRefTypesLookup rtl)
        {
            iRefTypesLookup = rtl;
        }

        public void CreateMappings()
        {
            Mapper.CreateMap<Journal, DisplayJournal>().AfterMap((j, dj) => dj.RefTypeName = iRefTypesLookup.Lookup(j.RefTypeID));
        }
    }

Finally, in my application startup, I fetch all instances of that interface in the container and call the CreateMappings method on them:

    var mappings = container.GetExportedValues<IMappingCreator>();

    foreach (IMappingCreator mc in mappings)
    {
        mc.CreateMappings();
    }

This makes the initial setup quite easy, as all the creation happens in one place, and you can have as many mapping creators as you want (however, you should keep those to a minimum, maybe once per project or so, grabbing all needed services for mapping the specific types in that project).

This is quite nice... I may have to borrow from this! :D MEF is such a great addition to the framework. — Daniel, Nov 21 '10 at 21:40
feel free to, I don't think I'm the only one coming up against this problem. — Femaref, Nov 21 '10 at 22:18

Gene S · Answer 4 · 2016-09-16T16:25:12.987

Here is the newest way of doing it...

https://pintoservice.wordpress.com/2016/01/31/dependency-injection-for-automapper-4-2-in-asp-net-vnext-mvc-project/

Although I personally add the auto-mappings in the controller, not in the repository. This way you can use the same repository for different controllers and have different mappings. Same concept though, just inject the IMapper in the controller instead of the repository.

Automapper together with Dependency Injection

4 Answers4

Linked