I would argue that you are violating two principles: the single responsibility principle (SRP) and the open/closed principle (OCP).

You are violating the SRP because the bootstrapping class have more than one reason to change: if you alter model binding or the auto mapper configuration.

You would be violating the OCP if you were to add additional bootstrapping code for configuring another sub-component of the system.

How I usually handle this is that I define the following interface.

public interface IGlobalConfiguration
{
    void Configure();
}

For each component in the system that needs bootstrapping I would create a class that implements that interface.

public class AutoMapperGlobalConfiguration : IGlobalConfiguration
{
    private readonly IConfiguration configuration;

    public AutoMapperGlobalConfiguration(IConfiguration configuration)
    {
        this.configuration = configuration;
    }

    public void Configure()
    {
        // Add AutoMapper configuration here.
    }
}

public class ModelBindersGlobalConfiguration : IGlobalConfiguration
{
    private readonly ModelBinderDictionary binders;

    public ModelBindersGlobalConfiguration(ModelBinderDictionary binders)
    {
        this.binders = binders;
    }

    public void Configure()
    {
        // Add model binding configuration here.
    }
}

I use Ninject to inject the dependencies. IConfiguration is the underlying implementation of the static AutoMapper class and ModelBinderDictionary is the ModelBinders.Binder object. I would then define a NinjectModule that would scan the specified assembly for any class that implements the IGlobalConfiguration interface and add those classes to a composite.

public class GlobalConfigurationModule : NinjectModule
{
    private readonly Assembly assembly;

    public GlobalConfigurationModule() 
        : this(Assembly.GetExecutingAssembly()) { }

    public GlobalConfigurationModule(Assembly assembly)
    {
        this.assembly = assembly;
    }

    public override void Load()
    {
        GlobalConfigurationComposite composite = 
            new GlobalConfigurationComposite();

        IEnumerable<Type> types = 
            assembly.GetExportedTypes().GetTypeOf<IGlobalConfiguration>()
                .SkipAnyTypeOf<IComposite<IGlobalConfiguration>>();

        foreach (var type in types)
        {
            IGlobalConfiguration configuration = 
                (IGlobalConfiguration)Kernel.Get(type);
            composite.Add(configuration);
        }

        Bind<IGlobalConfiguration>().ToConstant(composite);
    }
}

I would then add the following code to the Global.asax file.

public class MvcApplication : HttpApplication
{
    public void Application_Start()
    {
        IKernel kernel = new StandardKernel(
            new AutoMapperModule(),
            new MvcModule(),
            new GlobalConfigurationModule()
        );

        Kernel.Get<IGlobalConfiguration>().Configure();
    }
}

Now my bootstrapping code adheres to both SRP and OCP. I can easily add additional bootstrapping code by creating a class that implements the IGlobalConfiguration interface and my global configuration classes only have one reason to change.

To have it completely closed, you could have a static initializer per Mapping registration, but that would be overkill.

Some things are actually useful to have centralised to a degree from the point of view of being able to reverse engineer though.

In NInject, there is the notion of having a Module per project or subsystem (set of projects), which seems a sensible compromise.

I know this is an old one, but you might be interested to know that I have created a open source library called Bootstrapper that deals precisely with this issue. You might want to check it out. To avoid breaking the OC principle you need to define your mappers in separate classes that implement IMapCreater. Boostrapper will find these classes using reflection and will initialize all mappers at startup

If anything its the single responsibility principle that you are violating, in that the class has more than one reason to change.

I personally would have a ConfigureAutoMapper class which all my configuration for AutoMapper was done with. But it could be argued that it is down to personal choice.

Omu, I wrestle with similar questions when it comes to bootstrapping an IoC container in my app s startup routine. For IoC, the guidance I ve been given points to the advantage of centralizing your configuration rather than sprinkling it all over your app as you add changes. For configuring AutoMapper, I think the advantage of centralization is much less important. If you can get your AutoMapper container into your IoC container or Service Locator, I agree with Ruben Bartelink s suggestion of configuring the mappings once per assembly or in static constructors or something decentralized.

Basically, I see it as a matter of deciding whether you want to centralize the bootstrapping or decentralize it. If you are that concerned about the Open/Closed Principle on your startup routine, go with decentralizing it. But your adherence to OCP can be dialed down in exchange for the value of all your bootstrapping done in one place. Another option would be to have the bootstrapper scan certain assemblies for registries, assuming AutoMapper has such a concept.