AutoMapper is my tool of choice for mapping between types, mostly view models, DTO’s and domain models. In order to combine the powers of AutoMapper and StructureMap we have to do some plumbing. We need to register certain types in the IoC container and let AutoMapper know how to construct services. The combined power gives us the possibility to inject AutoMapper types wherever we want and we don’t have to work with the static Mapper class which I consider bad. Another benefit is that we can inject dependencies into custom type converters and value resolvers.
In this post I will try to explain my AutoMapper setup in conjunction with StructureMap in the context of ASP.NET MVC web applications. It shouldn't be that hard to port this information to other IoC frameworks as well.
Registries are the recommended way of defining a unit of configuration for StructureMap that can be applied to setup an container. The registry consists of two parts: manual and auto registration. The manual registration registers certain needed AutoMapper types where the IMappingEngine interface is the one you will be using the most and let you do the actual mapping of types. The ConfigurationStore is obviously also important and contains (after bootstrapping) all the type map configuration.
The auto registration part scans for all the AutoMapper profiles that will be used later during the bootstrapping of AutoMapper. The second scan also finds all custom implementations of type converters and value resolvers.
In this post I will only show the registry I use for AutoMapper 3.1.0 and 3.1.1. I also have links to registries that support AutoMapper 3.0.0 and 2.2.1. They are basically the same but the standard AutoMapper mapper registries are implemented differently in those versions.
The profiles are found by a simple custom convention. This convention checks if the type can be casted to a Profile and checks if the type has accessible constructors. Finding certain types with the StructureMap scanner doesn’t require you to create a custom convention but I use it to do some checking on the profile. I once ran into a situation that took me hours to find out why a certain profile wasn’t registered in the configuration store. As you can guess by now, it was because the profile had a private constructor that was put on there for some unknown reason and therefor StructureMap was unable to create an instance of the profile. The code for the custom convention is as follows.
Before we are able to start mapping we have to fill the configuration store with the actual type mapping configuration and tell AutoMapper how to resolve needed services like type converters and value resolvers. Every type map is defined inside the AutoMapper profiles that are found by the StructureMap scanner. In our bootstrapping we are going to retrieve all profiles and add them to the configuration store.
When you are building web applications, you can call the static Run method inside you application start or use something like WebActivator. That’s it, you are now able to request an instance of the IMappingEngine and you can start mapping.
This post is not about setting up StructureMap with ASP.NET MVC, bootstrapping StructureMap nor is it about requesting instances from StructureMap. There are a lot of resources out there that discusses those subjects.