Simple Injector

New Post: SimpleInjector Prism Bootstrapper

ObsidianPhoenix — Sat, 18 May 2013 10:55:12 GMT

Hi all,

So a colleague directed me towards SimpleInjector after viewing the stats here. He felt it had the right level of features for his MVC project, whilst being among the fastest around.

I'm starting a new prism app (still feeling my way around the basics of prism/MVVM to be honest), but I was wondering if there is a SI bootstrapper around anywhere for Prism?

If not, can someone point me in the direction of where I can see how the bootstrappers are constructed (i.e. what I'd need to do to roll my own).

Thanks
Fergal

Updated Wiki: How-to

dot_NET_Junkie — Fri, 17 May 2013 10:49:55 GMT

How To...

How to Register factory delegates
How to Resolve instances by key
How to Resolve array and lists
How to Register multiple interfaces with the same implementation
How to Override existing registrations
How to Verify the container's configuration
How to Work with dependency injection in multi-threaded applications

Register factory delegates

Simple Injector allows you to register a Func<T> delegate for the creation of an instance. This is especially useful in scenarios where it is impossible for the container to create the instance. There are overloads of the Register method available that accept an Func<T> argument:

container.Register<IMyService>(() => SomeSubSystem.CreateMyService());

In situations where a service needs to create multiple instances of a certain dependencies, or needs to explicitly control the lifetime of such dependency, abstract factories can be used. Instead of injecting an IMyService, you should inject an IMyServiceFactory that allows services to create new instances of IMyService:

// Definition
public interface IMyServiceFactory
{
    IMyService CreateNew();
}

// Implementation
sealed class ServiceFactory : IMyServiceFactory
{
    public IMyService CreateNew()
    {
        return new MyServiceImpl();
    }
}

// Registration
container.RegisterSingle<IMyServiceFactory, ServiceFactory>();

// Usage
public class MyService
{
    private readonly IMyServiceFactory factory;
    
    public MyService(IMyServiceFactory factory)
    {
        this.factory = factory;
    }
    
    public void SomeOperation()
    {
        using (var service1 = this.factory.CreateNew())
        {
            // use service 1
        }

        using (var service2 = this.factory.CreateNew())
        {
            // use service 2
        }
    }
}

Instead of creating specific interfaces for your factories, you can also choose to inject Func<T> delegates into your services:

// Registration
container.RegisterSingle<Func<IMyService>>(
    () => new MyServiceImpl());

// Usage
public class MyService
{
    private readonly Func<IMyService> factory;
    
    public MyService(Func<IMyService> factory)
    {
        this.factory = factory;
    }
    
    public void SomeOperation()
    {
        using (var service1 = this.factory.Invoke())
        {
            // use service 1
        }
    }
}

This saves you from having to define a new interface and implementation per factory.

Note: On the downside however, this communicates less clearly the intend of your code and as a result might make your code harder to grasp for other developers.

When you choose Func<T> delegates over specific factory interfaces, you can define the following extension method that makes it easier to register Func<T> factories:

// Extension method
container.RegisterFuncFactory<TService, TImplementation>(
    this Container container,
    Lifestyle lifestyle = null)
    where T : class
{
    lifestyle = lifestyle ?? Lifestyle.Transient;

    // Register the type explicitly to keep the configuration
    // verifiable.
    container.Register<TService, TImplementation>(lifestyle);
    
    // Register the Func<T> that resolves that instance.
    container.RegisterSingle<Func<TService>>(
        () => container.GetInstance<TService>());
}

// Registration
container.RegisterFuncFactory<IMyService, RealService>();

The previous extension method allowed registration of a single factory, but won't be maintainable when you want all registrations to be resolvable using Func<T> delegates by default.

Note: We personally think that allowing to register Func<T> delegates by default is a design smell. The use of Func<T> delegates makes your design harder to follow and your system harder to maintain and test. If you have many constructors in your system that depend on a Func<T>, please take a good look at your dependency strategy. If in doubt, please ask us here on CodePlex or on Stackoverflow.

The following extension method allows Simple Injector to resolve all types using a Func<T> delegate by default:

public static void AllowResolvingFuncFactories(
    this ContainerOptions options)
{
    var container = options.Container;

    container.ResolveUnregisteredType += (sender, e) =>
    {
        if (e.UnregisteredServiceType.IsGenericType &&
            e.UnregisteredServiceType.GetGenericTypeDefinition() ==
                typeof(Func<>))
        {
            Type serviceType = e.UnregisteredServiceType
                .GetGenericArguments().First();

            InstanceProducer registration =
                container.GetRegistration(serviceType);

            if (registration != null)
            {
                Type funcType =
                    typeof(Func<>).MakeGenericType(serviceType);

                var factoryDelegate = 
                    Expression.Lambda(funcType,
                        registration.BuildExpression())
                    .Compile();

                e.Register(Expression.Constant(factoryDelegate));
            }
        }
    };
}

// Registration
container.Options.AllowResolvingFuncFactories();

After calling the AllowResolvingFuncFactories extension method, the container allows resolving Func<T> delegates.

Just like Func<T> delegates can be injected, Lazy<T> instances can be injected into services. Lazy<T> is useful in situations where the creation of a service is time consuming, but is not always used. Thus Lazy<T> allows you to postpone the creation of that service until the moment that it is really needed:

// Extension method
container.RegisterLazy<T>(this Container container)
    where T : class
{
    Func<T> factory = () => container.GetInstance<T>();

    container.Register<Lazy<T>>(() => new Lazy<T>(factory));
}

// Registration    
container.RegisterLazy<IMyService>();

// Usage
public class MyService
{
    private readonly Lazy<IMyService> myService;
    
    public MyService(Lazy<IMyService> myService)
    {
        this.myService = myService;
    }
    
    public void SomeOperation()
    {
        if (someCondition)
        {
            this.myService.Value.Operate();
        }
    }
}

Note that instead of polluting the API of your application with Lazy<T> dependencies, it is usually cleaner to hide the Lazy<T> behind a proxy:

// Proxy definition
public class MyLazyServiceProxy : IMyService
{
    private readonly Lazy<IMyService> wrapped;
    
    public MyLazyServiceProxy(Lazy<IMyService> wrapped)
    {
        this.wrapped = wrapped;
    }
    
    public void Operate()
    {
        this.wrapped.Value.Operate();
    }
}

// Registration
container.RegisterLazy<IMyService>();
container.Register<IMyService, MyLazyServiceProxy>();

This way the application can simply depend on IMyService instead of Lazy<IMyService>.

Warning: The same warning applies to the use of Lazy<T> as it does for the use of Func<T> delegates. For more information about creating an application and container configuration that can be successfully verified, please read the How To Verify the container’s configuration.

Resolve instances by key

Resolving instances by a key is a feature that is deliberately left out of the Simple Injector, because we feel it steers developers to a design were the application tends to have a dependency on the DI container itself. For resolving a keyed instance, you will often need to call into the container itself, which leads to the Service Locator anti-pattern.

This doesn’t mean however, that resolving instances by a key is never useful. Resolving instances by a key however, is much more a job for a specific factory than for a container itself. This makes the design much cleaner, saves you from having to take a dependency on the DI framework, and enables many scenarios that the DI container writer just didn’t consider.

Note: The need for keyed registration can be an indication of ambiguity in the application design. Take a good look if each keyed registration shouldn't have its own unique interface, or perhaps each registration should implement each own version of a generic interface.

Take a look at the following scenario, where we want to retrieve instances of type IRequestHandler by a string key. There are of course several ways to achieve this, but here is a simple but effective way, by defining an IRequestHandlerFactory:

// Definition
public interface IRequestHandlerFactory
{
    IRequestHandler CreateNew(string name);
}

// Usage
var factory =
    container.GetInstance<IRequestHandlerFactory>();
var handler = factory.CreateNew("customers");
handler.Handle(requestContext);

By inheriting from the BCL’s Dictionary<TKey, TValue>, creating an IRequestHandlerFactory implementation, is almost a one-liner:

public class RequestHandlerFactory
    : Dictionary<string, Func<IRequestHandler>>,
    IRequestHandlerFactory
{
    public IRequestHandler CreateNew(string name)
    {
        return this[name]();
    }
}

With this class, we can register Func<IRequestHandler> factory methods by a key. With this in place the registration of keyed instances is a breeze:

var container = new Container();
 
container.RegisterSingle<IRequestHandlerFactory>(
    new RequestHandlerFactory
{
    { "default", () => container.GetInstance<DefaultRequestHandler>() },
    { "orders", () => container.GetInstance<OrdersRequestHandler>() },
    { "customers", () => container.GetInstance<CustomersRequestHandler>() },
});

Note: this design will work with almost all DI containers, making this not only a design that is easy to follow, but making it very easy to migrate to another DI implementation.

If you don’t like a design that uses Func<T> delegates this way, it can easily be changed to be a Dictionary<string, Type> instead. The RequestHandlerFactory can be implemented as follows:

public class RequestHandlerFactory
    : Dictionary<string, Type>, IRequestHandlerFactory
{
    private readonly Container container;
    
    public RequestHandlerFactory(Container container)
    {
        this.container = container;
    }

    public IRequestHandler CreateNew(string name)
    {
        var handler = this.container.GetInstance(this[name]);
        return (IRequestHandler)handler;
    }
}

The registration will then look as follows:

var container = new Container();

container.RegisterSingle<IRequestHandlerFactory>(
    new RequestHandlerFactory(container)
{
    { "default", typeof(DefaultRequestHandler) },
    { "orders", typeof(OrdersRequestHandler) },
    { "customers", typeof(CustomersRequestHandler) },
});

Note: Please remember the previous note about ambiguity in the application design. In the given example the design would probably be better af by using a generic IRequestHandler<TRequest> interface. This would allow the implementations to be batch registered using a single line of code, saves you from using keys, and results in a configuration the is verifiable by the container.

A last option to do keyed registrations is to manually create registrations and store them in a dictionary. The following example shows previous RequestHandlerFactory with this approach:

public class RequestHandlerFactory : IRequestHandlerFactory
{
    private readonly Dictionary<string, InstanceProducer> producers =
        new Dictionary<string, InstanceProducer>(
            StringComparer.OrdinalIgnoreCase);

    private readonly Container container;

    public RequestHandlerFactory(Container container)
    {
        this.container = container;
    }

    IRequestHandler IRequestHandlerFactory.CreateNew(string name)
    {
        var handler = this.producers[name].GetInstance();
        return (IRequestHandler)handler;
    }

    public void Register<TImplementation>(string name,
        Lifestyle lifestyle = null)
        where TImplementation : class, IRequestHandler
    {
        lifestyle = lifestyle ?? Lifestyle.Transient;

        var registration = lifestyle
            .CreateRegistration<IRequestHandler, TImplementation>(container);

        var producer =
            new InstanceProducer(typeof(IRequestHandler), registration);

        this.producers.Add(name, producer);
    }
}

The registration will then look as follows:

var container = new Container();

var factory = new RequestHandlerFactory(container);

factory.Register<DefaultRequestHandler>("default");
factory.Register<OrdersRequestHandler>("orders");
factory.Register<CustomersRequestHandler>("customers");

container.RegisterSingle<IRequestHandlerFactory>(factory);

The advantage of this method is that it completely integrates with the container. For instance, decorators can be applied to individual returned instances and types can be registered multiple times if needed.

Resolve array and lists

The Simple Injector allows registration of collections of elements using the RegisterAll method overloads. Collections can be resolved by using one of the GetAllInstances<T>() method, by calling GetInstance<IEnumerable<T>>(), or by defining an IEnumerable<T> parameter in the constructor of a type that is created using automatic constructor injection.

Injection of other collection types, such as arrays of T or IList<T> into constructors is not supported out of the box. By hooking onto the unregistered type resolution event however, this functionality can be added. Look here for an example extension method that allows this behavior for T[] types.

Please take a look at your design if you think you need to work with a collection of items. Often you can succeed by creating a composite type that can be injected. Take the following interface for instance:

public interface ILogger
{
    void Log(string message);
}

Instead of injecting a collection of dependencies, the consumer might not really be interested in the collection, but simply wishes to operate on all elements. In that scenario you can configure your container to inject a composite of that particular type. That composite might look as follows:

public sealed class CompositeLogger : ILogger
{
    private readonly ILogger[] loggers;

    public CompositeLogger(params ILogger[] loggers)
    {
        this.loggers = loggers ?? new ILogger[0];
    }

    public void Log(string message)
    {
        foreach (var logger in this.loggers)
        {
            logger.Log(message);
        }
    }
}

A composite allows you to remove this boilerplate iteration logic from the application, which makes the application cleaner and when changes have to be made to the way the collection of loggers is processed, only the composite has to be changed.

Register multiple interfaces with the same implementation

To adhere to the Interface Segregation Principle, it is important to keep interfaces narrow. Although in most situations implementations implement a single interface, it can sometimes be beneficial to have multiple interfaces on a single implementation. Here is an example of how to register this:

// Impl implements IInterface1, IInterface2 and IInterface3.
var registration =
    Lifestyle.Singleton.CreateRegistration<Impl, Impl>(container);

container.AddRegistration(typeof(IInterface1), registration);
container.AddRegistration(typeof(IInterface2), registration);
container.AddRegistration(typeof(IInterface3), registration);

var a = container.GetInstance<IInterface1>();
var b = container.GetInstance<IInterface2>();

// Since Impl is a singleton, both requests return the same instance.
Assert.AreEqual(a, b);

The first line creates a Registration instance for the Impl, in this case with a singleton lifestyle. The other lines add this registration to the container, once for each interface. This maps multiple service types to the exact same registration.

Override existing registrations

The default behavior of the Simple Injector is to fail when a service is registered for a second time. Most of the time the developer didn't intend to override a previous registration and allowing this would lead to a configuration that would pass the container's verification, but doesn't behave as expected.

There are certain scenarios however where overriding is useful. An example of such is a bootstrapper project for a Business layer that is reused in multiple applications (in both a web application, web service, and Windows service for instance). Not having a business layer specific bootstrapper project would mean the complete DI configuration would be duplicated in the startup path of each application, which would lead to code duplication. In that situation the applications would roughly have the same configuration, with a few adjustments.

Best is to start of by configuring all possible dependencies in the BL bootstrapper and leave out the service registrations where the implementation differs for each application. In other words, the BL bootstrapper would result in an incomplete configuration. After that, each application can finish the configuration by registering the missing dependencies. This way you still don't need to override the existing configuration.

In certain scenarios it can be beneficial to allow an application override an existing configuration. The container can be configured to allow overriding as follows:

var container = new Container();

container.Options.AllowOverridingRegistrations = true;

// Register IUserService.
container.Register<IUserService, FakeUserService>();

// Replaces the previous registration
container.Register<IUserService, RealUserService>();

The previous example created a Container instance that allows overriding. It is also possible to enable overriding half way the registration process:

// Create a container with overriding disabled
var container = new Container();

// Pass container to the business layer.
BusinessLayer.Bootstrapper.Bootstrap(container);

// Enable overriding
container.Options.AllowOverridingRegistrations = true;

// Replaces the previous registration
container.Register<IUserService, RealUserService>();

Verify the container’s configuration

Dependency Injection promotes the concept of programming against abstractions. This makes your code much easier to test, easier to change and more maintainable. However, since the code itself isn't responsible of maintaining the dependencies between implementations, the compiler will not be able to verify whether the dependency graph is correct.

When starting to use a Dependency Injection container, many developers see their application fail when it is deployed in staging or sometimes even production, because of container misconfigurations. This makes developers often conclude that dependency injection is bad, since the dependency graph cannot be verified. This conclusion however, is incorrect. Although it is impossible for the compiler to verify the dependency graph, verifying the dependency graph is still possible and advisable.

Simple Injector contains a Verify() method, that will simply iterate over all registrations and resolve an instance for each registration. Calling this method directly after configuring the container, allows the application to fail during start-up, when the configuration is invalid.

Calling the Verify() method however, is just part of the story. It is very easy to create a configuration that passes any verification, but still fails at runtime. Here are some tips to help building a verifiable configuration:

Stay away from implicit property injection, where the container is allowed to skip injecting the property if a corresponding or correctly registered dependency can't be found. This will disallow your application to fail fast and will result in NullReferenceExceptions later on. Only use implicit property injection when the property is truly optional, omitting the dependency still keeps the configuration valid, and the application still runs correctly without that dependency. Truly optional dependencies should be very rare though, since most of the time you should prefer injecting empty implementations (a.k.a. the Null Object pattern) instead of allowing dependencies to be a null reference. Explicit property injection on the other hand is fine. With explicit property injection you force the container to inject a property and it will fail when it can't succeed. However, you should prefer constructor injection whenever possible. Note that the need for property injection is often an indication of problems in the design. If you revert to property injection because you otherwise have too many constructor arguments, you're probably violating the Single Responsibility Principle.
Register all root objects explicitly if possible. For instance, register all ASP.NET MVC Controller instances explicitly in the container (Controller instances are requested directly and are therefore called 'root objects'). This way the container can check the complete dependency graph starting from the root object when you call Verify(). Prefer registering all root objects in an automated fashion, for instance by using reflection to find all root types. The Simple Injector ASP.NET MVC Integration NuGet Package for instance, contains a RegisterMvcControllers extension method that will do this for you and the WCF Integration NuGet Package contains a RegisterWcfServices extension method for this purpose.
If registering root objects is not possible or feasible, test the creation of each root object manually during start-up. With ASP.NET Web Form Page classes for instance, you will probably call the container from within their constructor (since Page classes must unfortunately have a default constructor). The key here again is finding them all in once using reflection. By finding all Page classes using reflection and instantiating them, you'll find out (during app start-up or through automated testing) whether there is a problem with your DI configuration or not. The Web Forms Integration guide contains an example of how to verify page classes.
There are scenarios where some dependencies cannot yet be created during application start-up. To ensure that the application can be started normally and the rest of the DI configuration can still be verified, abstract those dependencies behind a proxy or abstract factory. Try to keep those unverifiable dependencies to a minimum and keep good track of them, because you will probably have to test them manually.
But even when all registrations can be resolved succesfully by the container, that still doesn't mean your configuration is correct. It is very easy to accidentally misconfigure the container in a way that only shows up late in the development process. Simple Injector contains Debugger Diagnostics to help you spot common configuration mistakes. Use these diagnostic services and use them often.

Work with dependency injection in multi-threaded applications

Note: Simple Injector is designed for use in highly-concurrent applications. Its lock-free design allows it to scale linearly with the number of threads and processors in your system.

Many applications and application frameworks are inherently multi-threaded. Working in multi-threaded applications forces developers to take special care. It is easy for a less experienced developer to introduce a race condition in the code. Even although some frameworks such as ASP.NET make it easy to write thread-safe code, introducing a simple static field could break thread-safety.

This same holds when working with DI containers in multi-threaded applications. The developer that configures the container, should be aware of the risks of shared state. Not knowing which configured services are thread-safe is a sin. Registering a service that is not thread-safe as singleton, will eventually lead to concurrency bugs, that usually only appear in production code. Those bugs are often hard to reproduce and hard to find, making them costly to fix. And even when you correctly configured a service with the correct lifestyle, when another component that depends on it accidentally as a longer lifetime, the service might be kept alive much longer and might even be accessible from other threads.

Dependency injection however, can actually help in writing multi-threaded applications. Dependency injection forces you to wire all dependencies together in a single place in the application, the Composition Root. This means that there is a single place in the application that knows about how services behave, whether they are thread-safe, and how they should be wired. Without this centralization, this knowledge would be scattered throughout the code base, making it very hard to change the behavior of a service.

Tip: Take a close look at the 'Potential Lifestyle Mismatches' warnings in the Debugger Diagnostics. Lifestyle mismatches are a source of concurrency bugs.

In a multi-threaded application, each thread should get its own object graph. This means that you should typically call container.GetInstance<T>() once at the beginning of the thread to get the root object for processing that thread (or request). The container will build an object graph with all root object's dependencies. Some of those dependencies will be singletons; shared between all threads. Other dependencies might be transient; a new instance is created per dependency. Other dependencies might be thread-specific, request-specific, or with some other lifestyle. The application code itself is unaware of the way the dependencies are registered and that's the way it is supposed to be.

For web applications, you typically call GetInstance<T>() at the beginning of the web request. In an ASP.NET MVC application for instance, one Controller instance will be requested from the container (by the Controller Factory) per web request. When using one of the integration packages, such as the Simple Injector MVC Integration Quick Start NuGet package for instance, you don't have to call GetInstance<T>() yourself, the package will ensure this is done for you. Still, GetInstance<T>() is typically called once per request.

The advice of building a new object graph (calling GetInstance<T>()) at the beginning of a thread, also holds when manually starting a new thread. Although you can pass on data to other threads, you should not pass on container controlled dependencies to other threads. On each new thread, you should ask the container again for the dependencies. When you start passing dependencies from one thread to the other, those parts of the code have to know whether it is safe to pass those dependencies on. For instance, are those dependencies thread-safe? This might be trivial to analyze in some situations, but prevents you to change those dependencies with other implementations, since now you have to remember that there is a place in your code where this is happening and you need to know which dependencies are passed on. You are decentralizing this knowledge again, making it harder to reason about the correctness of your DI configuration and making it easier to misconfigure the container in a way that causes those concurrency problems.

Running code on a new thread can be done by adding a little bit of infrastructural code. Take for instance the following example where we want to send e-mail messages asynchronously. Instead of letting the caller implement this logic, it is better to hide the logic for asynchronicity behind an abstraction; a proxy. This ensures that this logic is centralized to a single place, and by placing this proxy inside the composition root, we prevent the application code to take a dependency on the container itself (which should be prevented).

// Synchronous implementation of IMailSender
public sealed class RealMailSender : IMailSender
{
    private readonly IMailFormatter formatter;
    
    public class RealMailSender(IMailFormatter formatter)
    {
        this.formatter = formatter;
    }

    void IMailSender.SendMail(string to, string message)
    {
        // format mail
        // send mail
    }
}

// Proxy for executing IMailSender asynchronously.
sealed class AsyncMailSenderProxy : IMailSender
{
    private readonly ILogger logger;
    private readonly Func<IMailSender> mailSenderFactory;

    public AsyncMailSenderProxy(ILogger logger,
        Func<IMailSender> mailSenderFactory)
    {
        this.logger = logger;
        this.mailSenderFactory = mailSenderFactory;
    }

    void IMailSender.SendMail(string to, string message)
    {
        // Run on a new thread
        Task.Factory.StartNew(() =>
        {
            this.SendMailAsync(to, message);
        });        
    }

    private void SendMailAsync(string to, string message)
    {
        // Here we run on a different thread and the
        // services should be requested on this thread.
        var mailSender = this.mailSenderFactory();

        try
        {
            mailSender.SendMail(to, message);
        }
        catch (Exception ex)
        {
            // logging is important, since we run on a
            // different thread.
            this.logger.Log(ex);
        }
    }
}

In the Composition Root, instead of registering the MailSender, we register the AsyncMailSenderProxy as follows:

container.Register<ILogger, FileLogger>(Lifestyle.Singleton);
container.Register<IMailSender, RealMailSender>();
container.RegisterSingleDecorator(typeof(IMailSender),
    typeof(AsyncMailSenderProxy));

In this case the container will ensure that when an IMailSender is requested, a single AsyncMailSenderProxy is returned with a Func<IMailSender> delegate that will create a new RealMailSender when requested. The RegisterDecorator and RegisterSingleDecorator overloads natively understand how to handle Func<Decoratee> dependencies. The Decorators section of the Advanced-scenarios wiki page explains more about registering decorators.

New Post: Register an Interface wich implementation's constructor has arguments

dot_NET_Junkie — Fri, 17 May 2013 08:37:58 GMT

View Models are created by your presentation layer (most often your controller, presenter, page, or whatever your pattern you're using) and are filled with data from the model and possibly other sources. Since this View Model class (this data package) is created using (almost) all run-time values, in shouldn't delegate the creation to your DI container. Further more, in general you're not interested to abstract the View Model from your View or Controller, because it is simply a data package.

If you still try this, you will find out very soon that this gets really awkward, and this holds not only when working with Simple Injector, but for all DI frameworks.

But when we ignore the fact that you're dealing with a view model, you can register types with a string parameter as follows (excuse my C#):

container.Register<ISomeService>(() => new SomeServiceImpl("somePath"));

And when you need to supply a runtime value, you can register a factory or register a Func<T> delegate as follows:

container.RegisterSingle<Func<string, ISomeService>>(
    path => new SomeServiceImpl(path));

New Post: Register an Interface wich implementation's constructor has arguments

The_Chaoz — Fri, 17 May 2013 01:51:38 GMT

Well I read the documentation but I couldn't find how to do this.
I've for example a class called "DocumentViewModel" wich constructor is something like:

Public Sub New(ByVal filepath As String)
    _filepath = New FilePath(filepath)
    //more code...
End Sub

How should I register this? And how should I implement this?

Thanks in advance

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

Sergeir — Mon, 13 May 2013 20:17:07 GMT

Thanks! - Adding the additional SetResolver call did the trick! Here is my final code:

  public static class SimpleInjectorInitializer
    {
        /// <summary>Initialize the container and register it as MVC3 Dependency Resolver.</summary>
        public static void Initialize()
        {
            var container = new Container();

            // register Web API controllers (important!)
            var controllerTypes =
                from type in Assembly.GetExecutingAssembly().GetExportedTypes()
                where typeof(IHttpController).IsAssignableFrom(type) // (typeof(IHttpController).IsAssignableFrom(type) || (typeof(IController).IsAssignableFrom(type) && type.Name != "HelpController"))
                where !type.IsAbstract
                where !type.IsGenericTypeDefinition
                where type.Name.EndsWith("Controller", StringComparison.Ordinal)
                select type;

            foreach (var controllerType in controllerTypes)
            {
                container.Register(controllerType);
            }

            // Register your types, for instance:
            container.Register<IRepository, Repository>();

            // register MVC controllers (This is an extension method from the integration package).
            container.RegisterMvcControllers(Assembly.GetExecutingAssembly());

            // register MVC attributes (This is an extension method from the integration package as well).
            container.RegisterMvcAttributeFilterProvider();

            // Verify the container configuration
            container.Verify();

            System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver =
                new SimpleInjectorWebApiDependencyResolver(container);

            System.Web.Mvc.DependencyResolver.SetResolver(
                new SimpleInjector.Integration.Web.Mvc.SimpleInjectorDependencyResolver(container));

        }
    }

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

dot_NET_Junkie — Mon, 13 May 2013 18:21:13 GMT

An assembly is not the same as an NuGet package. In fact, the MVC Quick Start Package itself, does not contain an assembly. It contains a reference to three other NuGet packages (two Simple Injector packages and the WebActivator package) and one content file.

Again, none of the dlls (assemblies) provided by Simple Injector reference the WebActivator. To integrate Simple Injector with MVC you don't need the MVC Quick Start package. The Quick Start is really just built to bootstrap everything together. If you don't want to use WebActivator, just deinstall the MVC Quick Start package and use the SimpleInjector.Integration.Web.Mvc NuGet package directly. The assembly in that package depends on SimpleInjector.dll and SimpleInjector.Integration.Web.dll and those are located in the NuGet packages with the same name.

SimpleInjector.Integration.Web.dll however, does not have a dependency on WebActivator. It only takes (besides SimpleInjector.dll) a dependency Microsoft.Web.Infrastructure.dll, which is part of the .NET framework.

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

omegaluz — Mon, 13 May 2013 15:54:28 GMT

The statement "none of the Simple Injector assemblies in fact have a dependency on WebActivator" seems to be incorrect. I just tried to uninstall WebActivator after uninstalling the Quick Start NuGet package and get the following:

"Unable to uninstall 'WebActivator 1.4.4' because 'SimpleInjector.Integration.Web 2.2.3' depend(s) on it."

New Post: Scenario questions about SI

androticus — Sun, 12 May 2013 16:05:13 GMT

That was all very helpful, thanks!

Updated Wiki: Home

dot_NET_Junkie — Sun, 12 May 2013 10:53:30 GMT

Welcome to the Simple Injector project

The Simple Injector is an easy-to-use Inversion of Control library for .NET and Silverlight.

Overview

The goal of Simple Injector is to provide .NET application developers with an easy, flexible, and fast dependency injection framework, that uses best practices to steers developers towards the pit of success.

Many of the existing IoC frameworks have a big complicated legacy API or are are new, immature, and lack the features do be used in large developement projects. Simple Injector solves this problem by supplying a simple implementation with a very limited set of carefully chosen features in its core library. For example, file- and attribute-based configuration methods (that result in brittle and maintenance heavy applications) have been abandoned, favoring simple code-based configuration instead. This is enough for most applications, requiring only that configuration be performed at the start of the program. Although the API is limited, the core library does contain many features and allows almost any advanced scenario.

You will need .NET 4.0 or up to use the Simple Injector 2 library. (For .NET 3.5 projects you can use the Simple Injector v1.x releases).
Simple Injector is carefully designed to run in partial trust.
Simple Injector runs in Silverlight 4 and up (Silverlight for Windows Phone is not supported).
Simple Injector 2 runs on Mono.
It is fast; blazingly fast.

New Diagnostic Services in Simple Injector 2

Simple Injector version 2 adds the ability to warn about common misconfigurations while debugging the application. Many Simple Injector users have already used this feature to diagnose their configuration and have successfully fixed problems that would be very hard to find otherwise. Here's a quick example of how this might look in the debugger:

See the Debug Diagnostic Services page for more information.

Getting started

If you're using NuGet, there are NuGet packages available. Take a look here. Otherwise, follow the steps below, to start using the Simple Injector:

Go to the Downloads tab and download the latest runtime library;
Unpack the downloaded .zip file;
Add the SimpleInjector.dll to your start-up project by right-clicking on a project in the Visual Studio solution explorer and selecting 'Add Reference...'.
Add the using SimpleInjector; using directive on the top of the code file where you wish to configure the application.
Look at the Usage section in the documentation on how to configure and use the Simple Injector.
Look at the More information section if you want to learn more or have any questions.

A Quick Example

The general idea behind the Simple Injector (or any DI framework for that matter) is that you design your application around loosely coupled components using the dependency injection pattern. Take for instance the following UserController class in the context of an ASP.NET MVC application:

Note: Simple Injector works for many different technologies, not only for MVC. Please look at the Integration Guide for help using the Simple Injector with your technology of choice.

public class UserController : Controller {
    private readonly IUserRepository repository;
    private readonly ILogger logger;

    // Use constructor injection for the dependencies
    public UserService(IUserRepository rep, ILogger logger) {
        this.repository = rep;
        this.logger = logger;
    }

    // implement UserController methods here:
    public ActionResult Index() {
        this.logger.Log("Index called");
        return View(this.rep.GetAll());
    }	
}

The UserController class depends on the IUserRepository and ILogger interfaces. By not depending on concrete implementations, we can test UserController in isolation. Ease of testing is however, just the start of what Dependency Injection will accomplish. It allows us to design highly flexible systems that can completely be composed at a single place (often the startup path) in the application.

Using the Simple Injector, the configuration of the application using the UserController class, could look as follows:

protected void Application_Start(object sender, EventArgs e) {
    // 1. Create a new Simple Injector container
    var container = new Container();

    // 2. Configure the container (register)
    container.Register<IUserRepository, SqlUserRepository>();

    container.RegisterSingle<ILogger>(() => new CompositeLogger(
        container.GetInstance<DatabaseLogger>(),
        container.GetInstance<MailLogger>()
    ));

    // 3. Optionally verify the container's configuration.
    container.Verify();

    // 4. Register the container as MVC3 IDependencyResolver.
    DependencyResolver.SetResolver(new SimpleInjectorDependencyResolver(container));
}

Tip: If you start with a MVC application, use the NuGet Simple Injector MVC Integration Quick Start package.

The given configuration registers implementations for the IUserRepository and ILogger interfaces. The code snippet shows a few interesting things. First of all, you can map concrete instances (such as SqlUserRepository) to an interface or base type. In the given example, every time you ask the container for an IUserRepository, it will create a new SqlUserRepository on your behalf (in DI terminology: an object with a Transient lifestyle).

The registration of the ILogger is a bit more complex though. It registers a delegate that knows how to create a new ILogger implementation, in this case CompositeLogger (which is an implementation of ILogger). The delegate itself calls back into the container and this allows the container to create the concrete DatabaseLogger and MailLogger and inject them into the CompositeLogger. While the type of registration that we’ve seen with the IUserRepository is much more common, the use of delegates allows many interesting scenarios.

Note: We did not register the UserController, because the UserController is a concrete type, Simple Injector can implicitly create it (as long as its dependencies can be resolved).

This is in fact all it takes to start using the Simple Injector. Design your classes around the dependency injection principle (which is actually the hard part) and configure them in the top of your application. Some frameworks (such as ASP.NET MVC) will do the rest for you. Other frameworks (like ASP.NET Web Forms) will need a little bit more work to get this done. See the Integration Guide for examples of your framework of choice.

Please go to the Using the Simple Injector section in the documentation to see more examples.

More information

For more information about the Simple Injector please visit the following links:

Using the Simple Injector will guide you through the Simple Injector basics.
The Simple Injector and object lifetime management page explains how to configure lifestyles such as transient, singleton, and many others.
See the Reference library for the complete API documentation.
See the Integration Guide for more information about how to integrate the Simple Injector into your specific application framework.
For more information about dependency injection in general, please visit this page on Stackoverflow.
If you have any questions about how to use the Simple Injector or about dependency injection in general, the experts at Stackoverflow.com are waiting for you.
For all other Simple Injector related question and discussions, such as bug reports and feature requests, the Simple Injector discussion forum will be the place to start.

Happy injecting!

This project is supported by

Simple Injector Twitter Feed

_{Twitter / simpleinjector News Feed
simpleinjector: Hi @rossipedia. Please post a question on the http://t.co/9Q0ED2Yk discussion forum or stackoverflow http://t.co/L1eTCQoL with more info.
Monday, September 24, 2012 | From Twitter / simpleinjector
simpleinjector: RT @NuGetLatest: SimpleInjector.Integration.Wcf 1.5.0.12267 http://t.co/N4vkPAbs
Sunday, September 23, 2012 | From Twitter / simpleinjector
simpleinjector: #simpleinjector #WCF Integration Guide: http://t.co/5qSVQu1Z and #NuGet package: https://t.co/ceDMj7YI
Sunday, September 23, 2012 | From Twitter / simpleinjector
simpleinjector: #simpleinjector Integration Guide for http://t.co/s4u4dx9N Web API http://t.co/tGxmP95H
Saturday, September 22, 2012 | From Twitter / simpleinjector
simpleinjector: Just published a new patch release of #SimpleInjector Extensions to #NuGet http://t.co/VTw9P23A Fixes a few bugs with RegisterOpenGeneric
Saturday, August 25, 2012 | From Twitter / simpleinjector
Twitter / simpleinjector News Feed}

New Post: Scenario questions about SI

dot_NET_Junkie — Sat, 11 May 2013 10:18:25 GMT

Simple Injector does not allow resolving Lifetime Scoped instances outside the context of a scope. This design is deliberate. One of the earlier versions of the framework in fact behaved differently and followed the design of Autofac and other containers to return a singleton instance in the case there was no scope.

This design however proved to be bad, since returning a singleton is almost always a bad idea, since components are often registered with Lifetime Scope because they are not thread-safe and should not be reused. A great example of this is the Unit of Work pattern that Entity Framework implements with its DbContext and ObjectContext classes. We saw users spinning off background threads and forget to start a new scope, which caused their Unit of Work class to be shared over multiple threads, which lead to errors in production.

Because of this we decided to disallow this by default. Perhaps your case is different and it is okay to return a default instance. If you really want to do this, you can enable this by using a Hybrid lifestyle, as follows:

var scopedLifestyleWithSingletonFallback = Lifestyle.CreateHybrid(
    () => container.GetCurrentLifetimeScope() != null,
    new LifetimeScopeLifestyle(),
    Lifestyle.Singleton); // the fallback lifestyle

But please take a look carefully at your design if this really is what you need and if it is possible for a programmer to make a mistake in such way that things accidentally are returned as singleton, while it should have been scoped. Since you are running a Windows Service that spins of new threads to do its work, it seems very unlikely that any code should even run outside the context of a lifetime scope.

When you spin of a background thread and have any components registered as Lifetime Scope, you will have to wrap the execution with a lifetime scope. You will have to start the scope before requesting the root object, for instance:

Task.Factory.StartNew(() =>
{
    using (container.BeginLifetimeScope())
    {
         // resolve root object
         var service = container.GetInstance<ISomeService>();
         service.Do();
    }
}

This code should be part of your application's Composition Root and not of any application code. This prevents the application to know anything about it. Of course the code cannot run without outside the context of a lifetime scope, but this is quite obvious. The fact that the consumer should now as little as possible doesn't mean it should be able to work in any case. Not starting a scope is a misconfiguration and you'd rather see the application fail than silently continue in error. Neither would you want the application to continue when one of your registrations is missing. You should always fail fast.

I want the middleware to use the logging object that is for that specific service.

This seems more like Context Based Injection.

Lifetime Scoping in Simple Injector differs from the concept of Child Containers that frameworks such as Unity use. A child container allows you to do special registrations in that child container. Simple Injector does use this approach, since it is impossible to both allow creating child containers with new registrations and having good performance at the same time. If I understand correctly you want to register a new instance at the beginning of the thread and reuse that same instance for the duration of that scope. There are several ways to do this. Here is an idea:

// Registration
container.RegisterLifetimeScope<LoggerContext>();

container.RegisterLifetimeScope<ILogger>(
    () => container.GetInstance<LoggerContext>().Logger ?? 
        NullLogger.Instance);

// This class is unknown to the application, only known in 
// the composition root.
public class LoggerContext
{
    public ILogger Logger { get; set; }
}

// Part of the Compostion root that starts a use case:
Task.Factory.StartNew(() =>
{
    using (container.BeginLifetimeScope())
    {
        // Set the logger to be used during this scope.
        container.GetInstance<LoggerContext>().Logger =
            new Logger(typeof(ISomeService), "special stuff");
    
         // resolve root object
         var service = container.GetInstance<ISomeService>();
         service.Do();
    }
}

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

dot_NET_Junkie — Sat, 11 May 2013 09:35:43 GMT

What is exactly the problem you are having?

Although not advised, integrating MVC and Web API in the same project is possible. But since both frameworks have their own API for dependency resolution, you will have to make sure that you register both the MVC DependencyResolver and the Web API DependencyResolver, like this:

System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver =
    new SimpleInjectorWebApiDependencyResolver(container);
        
System.Web.Mvc.DependencyResolver.SetResolver(
    new SimpleInjector.Integration.Web.Mvc.SimpleInjectorDependencyResolver(container));

New Post: Scenario questions about SI

androticus — Fri, 10 May 2013 21:34:45 GMT

Here is code for the Scoped Instance Scenario (I will provide the other scenario in another message). I think it is easiest with the concrete use- case, which is for a logging interface. We have a lot of code that is in windows services, where the code provides several different services running on different threads using different loggers. When I make a call to the middleware in a scoped instance from one of those threads, I want the middleware to use the logging object that is for that specific service. The example below is for some middleware service ISomeService that takes a ILogger which I want to supply. I want to set that instance of the Logger in the scope so that all DI resolutions within that scope will use that logger instance.

//ctor for SomeService : ISomeService

public SomeService(ILogger logger) {
...
}

// sample scenario:
Container container = new Container();

// global registrations not shown
container.Register<ISomeService, SomeService>(new LifestyleScoped());

using (container.BeginLifetimeScope())
{

container.RegisterSingle<ILogger>(anExistingLoggerInstance); // THIS IS WHAT I WANT TO DO

...

//
ISomeService svc = container.GetInstance<ISomeService >(); // SHOULD GET CONSTRUCTED WITH THE INSTANCE I SET

}

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

Sergeir — Fri, 10 May 2013 20:32:56 GMT

I have an MVC 4 ASP.NET Web API project in which I want to be able to inject a repository into both a MVC controller and an Web API controller. Obviously the project itself supports both types of controllers. I have found documentation on the Simple Injector site which shows how to implement either but not both at once.

I have tried several methods, both of which can be seen in the code below, to no avail:

 public static class SimpleInjectorInitializer
    {
        /// <summary>Initialize the container and register it as MVC3 Dependency Resolver.</summary>
        public static void Initialize()
        {
            var container = new Container();

            // register Web API controllers (important!)
            var controllerTypes =
                from type in Assembly.GetExecutingAssembly().GetExportedTypes()
                where typeof(IHttpController).IsAssignableFrom(type) 
                where !type.IsAbstract
                where !type.IsGenericTypeDefinition
                where type.Name.EndsWith("Controller", StringComparison.Ordinal)
                select type;

            foreach (var controllerType in controllerTypes)
            {
                container.Register(controllerType);
            }

            // Register your types, for instance:
            container.Register<IRepository, Repository>();

            // register MVC controllers (This is an extension method from the integration package).
            container.RegisterMvcControllers(Assembly.GetExecutingAssembly());

            // register MVC controllers - second method (This is an extension method from the integration package).
            //var mvcControllerTypes =
            //    from type in SimpleInjectorMvcExtensions.GetControllerTypesToRegister(container, Assembly.GetExecutingAssembly())
            //    where type.Name != "HelpController"
            //    select type;

            //foreach (Type controllerType in mvcControllerTypes)
            //{
            //    container.Register(controllerType);
            //}

            // register MVC attributes (This is an extension method from the integration package as well).
            container.RegisterMvcAttributeFilterProvider();

            // Verify the container configuration
            container.Verify();

            // Register the dependency resolver.
            GlobalConfiguration.Configuration.DependencyResolver =
                new SimpleInjectorWebApiDependencyResolver(container);
        }
    }

Here is the SimpleInjectorWebApiDependencyResolver calss taken from the Web API guide:

public sealed class SimpleInjectorWebApiDependencyResolver
    : IDependencyResolver
{
    private readonly Container container;

    public SimpleInjectorWebApiDependencyResolver(
        Container container)
    {
        this.container = container;
    }

    [DebuggerStepThrough]
    public IDependencyScope BeginScope()
    {
        return this;
    }

    [DebuggerStepThrough]
    public object GetService(Type serviceType)
    {
        return ((IServiceProvider)this.container)
            .GetService(serviceType);
    }

    [DebuggerStepThrough]
    public IEnumerable<object> GetServices(Type serviceType)
    {
        return this.container.GetAllInstances(serviceType);
    }

    [DebuggerStepThrough]
    public void Dispose()
    {
    }
}

http://simpleinjector.codeplex.com/wikipage?title=Web%20API%20Integration
http://simpleinjector.codeplex.com/wikipage?title=MVC%20Integration

Updated Wiki: How-to

dot_NET_Junkie — Fri, 10 May 2013 16:23:27 GMT

How To...

How to Register factory delegates
How to Resolve instances by key
How to Resolve array and lists
How to Register multiple interfaces with the same implementation
How to Override existing registrations
How to Verify the container's configuration
How to Work with dependency injection in multi-threaded applications

Register factory delegates

container.Register<IMyService>(() => SomeSubSystem.CreateMyService());

// Definition
public interface IMyServiceFactory
{
    IMyService CreateNew();
}

// Implementation
sealed class ServiceFactory : IMyServiceFactory
{
    public IMyService CreateNew()
    {
        return new MyServiceImpl();
    }
}

// Registration
container.RegisterSingle<IMyServiceFactory, ServiceFactory>();

// Usage
public class MyService
{
    private readonly IMyServiceFactory factory;
    
    public MyService(IMyServiceFactory factory)
    {
        this.factory = factory;
    }
    
    public void SomeOperation()
    {
        using (var service1 = this.factory.CreateNew())
    	{
            // use service 1
        }

        using (var service2 = this.factory.CreateNew())
    	{
            // use service 2
        }
    }
}

Instead of creating specific interfaces for your factories, you can also choose to inject Func<T> delegates into your services:

// Registration
container.RegisterSingle<Func<IMyService>>(
    () => new MyServiceImpl());

// Usage
public class MyService
{
    private readonly Func<IMyService> factory;
    
    public MyService(Func<IMyService> factory)
    {
        this.factory = factory;
    }
    
    public void SomeOperation()
    {
        using (var service1 = this.factory.Invoke())
    	{
            // use service 1
        }
    }
}

This saves you from having to define a new interface and implementation per factory.

Note: On the downside however, this communicates less clearly the intend of your code and as a result might make your code harder to grasp for other developers.

When you choose Func<T> delegates over specific factory interfaces, you can define the following extension method that makes it easier to register Func<T> factories:

// Extension method
container.RegisterFuncFactory<TService, TImplementation>(
    this Container container,
    Lifestyle lifestyle = null)
    where T : class
{
    lifestyle = lifestyle ?? Lifestyle.Transient;

    // Register the type explicitly to keep the configuration
    // verifiable.
    container.Register<TService, TImplementation>(lifestyle);
	
    // Register the Func<T> that resolves that instance.
    container.RegisterSingle<Func<TService>>(
        () => container.GetInstance<TService>());
}

// Registration
container.RegisterFuncFactory<IMyService, RealService>();

The previous extension method allowed registration of a single factory, but won't be maintainable when you want all registrations to be resolvable using Func<T> delegates by default.

Note: We personally think that allowing to register Func<T> delegates by default is a design smell. The use of Func<T> delegates makes your design harder to follow and your system harder to maintain and test. If you have many constructors in your system that depend on a Func<T>, please take a good look at your dependency strategy. If in doubt, please ask us here on CodePlex or on Stackoverflow.

The following extension method allows Simple Injector to resolve all types using a Func<T> delegate by default:

public static void AllowResolvingFuncFactories(
    this ContainerOptions options)
{
    var container = options.Container;

    container.ResolveUnregisteredType += (sender, e) =>
    {
        if (e.UnregisteredServiceType.IsGenericType &&
            e.UnregisteredServiceType.GetGenericTypeDefinition() ==
                typeof(Func<>))
        {
            Type serviceType = e.UnregisteredServiceType
                .GetGenericArguments().First();

            InstanceProducer registration =
                container.GetRegistration(serviceType);

            if (registration != null)
            {
                Type funcType =
                    typeof(Func<>).MakeGenericType(serviceType);

                var factoryDelegate = 
                    Expression.Lambda(funcType,
                        registration.BuildExpression())
                    .Compile();

                e.Register(Expression.Constant(factoryDelegate));
            }
        }
    };
}

// Registration
container.Options.AllowResolvingFuncFactories();

// Extension method
container.RegisterLazy<T>(this Container container)
    where T : class
{
    Func<T> factory = () => container.GetInstance<T>();

    container.Register<Lazy<T>>(() => new Lazy<T>(factory));
}

// Registration    
container.RegisterLazy<IMyService>();

// Usage
public class MyService
{
    private readonly Lazy<IMyService> myService;
    
    public MyService(Lazy<IMyService> myService)
    {
        this.myService = myService;
    }
    
    public void SomeOperation()
    {
        if (someCondition)
        {
            this.myService.Value.Operate();
        }
    }
}

Note that instead of polluting the API of your application with Lazy<T> dependencies, it is usually cleaner to hide the Lazy<T> behind a proxy:

// Proxy definition
public class MyLazyServiceProxy : IMyService
{
    private readonly Lazy<IMyService> wrapped;
    
    public MyLazyServiceProxy(Lazy<IMyService> wrapped)
    {
        this.wrapped = wrapped;
    }
    
    public void Operate()
    {
        this.wrapped.Value.Operate();
    }
}

// Registration
container.RegisterLazy<IMyService>();
container.Register<IMyService, MyLazyServiceProxy>();

This way the application can simply depend on IMyService instead of Lazy<IMyService>.

Warning: The same warning applies to the use of Lazy<T> as it does for the use of Func<T> delegates. For more information about creating an application and container configuration that can be successfully verified, please read the How To Verify the container’s configuration.

Resolve instances by key

Note: The need for keyed registration can be an indication of ambiguity in the application design. Take a good look if each keyed registration shouldn't have its own unique interface, or perhaps each registration should implement each own version of a generic interface.

// Definition
public interface IRequestHandlerFactory
{
    IRequestHandler CreateNew(string name);
}

// Usage
var factory =
    container.GetInstance<IRequestHandlerFactory>();
var handler = factory.CreateNew("customers");
handler.Handle(requestContext);

By inheriting from the BCL’s Dictionary<TKey, TValue>, creating an IRequestHandlerFactory implementation, is almost a one-liner:

public class RequestHandlerFactory
    : Dictionary<string, Func<IRequestHandler>>,
    IRequestHandlerFactory
{
    public IRequestHandler CreateNew(string name)
    {
        return this[name]();
    }
}

With this class, we can register Func<IRequestHandler> factory methods by a key. With this in place the registration of keyed instances is a breeze:

var container = new Container();
 
container.RegisterSingle<IRequestHandlerFactory>(
    new RequestHandlerFactory
{
    { "default", () => container.GetInstance<DefaultRequestHandler>() },
    { "orders", () => container.GetInstance<OrdersRequestHandler>() },
    { "customers", () => container.GetInstance<CustomersRequestHandler>() },
});

Note: this design will work with almost all DI containers, making this not only a design that is easy to follow, but making it very easy to migrate to another DI implementation.

If you don’t like a design that uses Func<T> delegates this way, it can easily be changed to be a Dictionary<string, Type> instead. The RequestHandlerFactory can be implemented as follows:

public class RequestHandlerFactory
    : Dictionary<string, Type>, IRequestHandlerFactory
{
    private readonly Container container;
    
    public RequestHandlerFactory(Container container)
    {
        this.container = container;
    }

    public IRequestHandler CreateNew(string name)
    {
        var handler = this.container.GetInstance(this[name]);
        return (IRequestHandler)handler;
    }
}

The registration will then look as follows:

var container = new Container();

container.RegisterSingle<IRequestHandlerFactory>(
    new RequestHandlerFactory(container)
{
    { "default", typeof(DefaultRequestHandler) },
    { "orders", typeof(OrdersRequestHandler) },
    { "customers", typeof(CustomersRequestHandler) },
});

Note: Please remember the previous note about ambiguity in the application design. In the given example the design would probably be better af by using a generic IRequestHandler<TRequest> interface. This would allow the implementations to be batch registered using a single line of code, saves you from using keys, and results in a configuration the is verifiable by the container.

Resolve array and lists

public interface ILogger
{
    void Log(string message);
}

public sealed class CompositeLogger : ILogger
{
    private readonly ILogger[] loggers;

    public CompositeLogger(params ILogger[] loggers)
    {
        this.loggers = loggers ?? new ILogger[0];
    }

    public void Log(string message)
    {
        foreach (var logger in this.loggers)
        {
            logger.Log(message);
        }
    }
}

Register multiple interfaces with the same implementation

// Impl implements IInterface1, IInterface2 and IInterface3.
var registration =
    Lifestyle.Singleton.CreateRegistration<Impl, Impl>(container);

container.AddRegistration(typeof(IInterface1), registration);
container.AddRegistration(typeof(IInterface2), registration);
container.AddRegistration(typeof(IInterface3), registration);

var a = container.GetInstance<IInterface1>();
var b = container.GetInstance<IInterface2>();

// Since Impl is a singleton, both requests return the same instance.
Assert.AreEqual(a, b);

Override existing registrations

var container = new Container();

container.Options.AllowOverridingRegistrations = true;

// Register IUserService.
container.Register<IUserService, FakeUserService>();

// Replaces the previous registration
container.Register<IUserService, RealUserService>();

The previous example created a Container instance that allows overriding. It is also possible to enable overriding half way the registration process:

// Create a container with overriding disabled
var container = new Container();

// Pass container to the business layer.
BusinessLayer.Bootstrapper.Bootstrap(container);

// Enable overriding
container.Options.AllowOverridingRegistrations = true;

// Replaces the previous registration
container.Register<IUserService, RealUserService>();

Verify the container’s configuration

Stay away from implicit property injection, where the container is allowed to skip injecting the property if a corresponding or correctly registered dependency can't be found. This will disallow your application to fail fast and will result in NullReferenceExceptions later on. Only use implicit property injection when the property is truly optional, omitting the dependency still keeps the configuration valid, and the application still runs correctly without that dependency. Truly optional dependencies should be very rare though, since most of the time you should prefer injecting empty implementations (a.k.a. the Null Object pattern) instead of allowing dependencies to be a null reference. Explicit property injection on the other hand is fine. With explicit property injection you force the container to inject a property and it will fail when it can't succeed. However, you should prefer constructor injection whenever possible. Note that the need for property injection is often an indication of problems in the design. If you revert to property injection because you otherwise have too many constructor arguments, you're probably violating the Single Responsibility Principle.
Register all root objects explicitly if possible. For instance, register all ASP.NET MVC Controller instances explicitly in the container (Controller instances are requested directly and are therefore called 'root objects'). This way the container can check the complete dependency graph starting from the root object when you call Verify(). Prefer registering all root objects in an automated fashion, for instance by using reflection to find all root types. The Simple Injector ASP.NET MVC Integration NuGet Package for instance, contains a RegisterMvcControllers extension method that will do this for you and the WCF Integration NuGet Package contains a RegisterWcfServices extension method for this purpose.
If registering root objects is not possible or feasible, test the creation of each root object manually during start-up. With ASP.NET Web Form Page classes for instance, you will probably call the container from within their constructor (since Page classes must unfortunately have a default constructor). The key here again is finding them all in once using reflection. By finding all Page classes using reflection and instantiating them, you'll find out (during app start-up or through automated testing) whether there is a problem with your DI configuration or not. The Web Forms Integration guide contains an example of how to verify page classes.
There are scenarios where some dependencies cannot yet be created during application start-up. To ensure that the application can be started normally and the rest of the DI configuration can still be verified, abstract those dependencies behind a proxy or abstract factory. Try to keep those unverifiable dependencies to a minimum and keep good track of them, because you will probably have to test them manually.
But even when all registrations can be resolved succesfully by the container, that still doesn't mean your configuration is correct. It is very easy to accidentally misconfigure the container in a way that only shows up late in the development process. Simple Injector contains Debugger Diagnostics to help you spot common configuration mistakes. Use these diagnostic services and use them often.

Work with dependency injection in multi-threaded applications

Note: Simple Injector is designed for use in highly-concurrent applications. Its lock-free design allows it to scale linearly with the number of threads and processors in your system.

Tip: Take a close look at the 'Potential Lifestyle Mismatches' warnings in the Debugger Diagnostics. Lifestyle mismatches are a source of concurrency bugs.

// Synchronous implementation of IMailSender
public sealed class RealMailSender : IMailSender
{
    private readonly IMailFormatter formatter;
    
    public class RealMailSender(IMailFormatter formatter)
    {
        this.formatter = formatter;
    }

    void IMailSender.SendMail(string to, string message)
    {
        // format mail
        // send mail
    }
}

// Proxy for executing IMailSender asynchronously.
sealed class AsyncMailSenderProxy : IMailSender
{
    private readonly ILogger logger;
    private readonly Func<IMailSender> mailSenderFactory;

    public AsyncMailSenderProxy(ILogger logger,
        Func<IMailSender> mailSenderFactory)
    {
        this.logger = logger;
        this.mailSenderFactory = mailSenderFactory;
    }

    void IMailSender.SendMail(string to, string message)
    {
        // Run on a new thread
        Task.Factory.StartNew(() =>
        {
            this.SendMailAsync(to, message);
        });        
    }

    private void SendMailAsync(string to, string message)
    {
        // Here we run on a different thread and the
        // services should be requested on this thread.
        var mailSender = this.mailSenderFactory();

        try
        {
            mailSender.SendMail(to, message);
        }
        catch (Exception ex)
        {
            // logging is important, since we run on a
            // different thread.
            this.logger.Log(ex);
        }
    }
}

In the Composition Root, instead of registering the MailSender, we register the AsyncMailSenderProxy as follows:

container.Register<ILogger, FileLogger>(Lifestyle.Singleton);
container.Register<IMailSender, RealMailSender>();
container.RegisterSingleDecorator(typeof(IMailSender),
    typeof(AsyncMailSenderProxy));

New Post: Scenario questions about SI

dot_NET_Junkie — Thu, 09 May 2013 19:44:33 GMT

I'm afraid I don't fully understand your question. Could you please supply me with some more details?

You cannot request an instance of a service that has been registered as scoped in a global context.

Are you talking about the Lifetime Scope lifestyle?
Do you mean that you can't get an instance when you didn't call container.BeginLifetimeScope()?

No apparent way to set a scoped instance

Can you supply me with a concrete (realistic) code example of what you're trying to achieve?

New Post: Scenario questions about SI

androticus — Thu, 09 May 2013 19:08:16 GMT

I have been evaluating Simple Injector, and am having challenges with the following scenarios. I was hoping for some comments:

Scoped registration and instancing are tightly coupled and code must be aware

You cannot request an instance of a service that has been registered as scoped in a global context. You can only register as scoped, and then need to retrieve as scoped. This seems to violate a principle that the consumer of the service should need to know as little as possible about details like this.

No apparent way to set a scoped instance

You can manually set instances of globally scoped services, but you can't seem to set instances of scoped services. Example scenarios:
Outer, global logging instance. Some scoped calls would like to supply a scoped logging object that applies to the calling context.
Outer, global security credentials object. Calls outside a scope want to use the global security credentials, but some scoped calls provide their own credentials, want to set those.

I realize you can probably do this stuff with various specialized Factory objects and/or instance caches etc., but that seems to defeat the purpose of having a DI framework. Thanks for any feedback!

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

dot_NET_Junkie — Thu, 09 May 2013 18:57:41 GMT

I must admit that I myself prefer the use of the Global.asax and Application_Start. I do use the Quick Start package, but copy the need configuration to the Global.asax and uninstall the package afterwards.

The use of the WebActivator however, was chosen because this allowed users to get started with Simple Injector just by pulling in the "Simple Injector MVC Integration Quick Start" NuGet package. That package just contains some references to other NuGet packages and one single content file. Adding a content file is a very safe. It prevents having to use tricky Visual Studio integration, which would be needed when an existing Application_Start was altered. Besides, the addition of one single content file is much easier to grasp for developers, compared to finding out that existing files and code has been altered by some package.

So we went for the safest way that is easiest to explain to developers. If this doesn't suit you (as it doesn't really suit myself either), I advice you to just do what I do: copy that code to the Application_Start and uninstall that package.

Note that that although the Quick Start NuGet package takes a dependency on WebActivator, none of the Simple Injector assemblies in fact have a dependency on WebActivator, so from an architectural perspective there's no problem here. And again, if you don't want to take a dependency on WebActivator, just uninstall the Quick Start NuGet package and you're fine.

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

omegaluz — Thu, 09 May 2013 18:04:18 GMT

Personally, I like the direction the MVC team has gone in recent years in regards to any application_start code. Take any of the following for examples:

protected void Application_Start(Object sender, EventArgs e)
    {

        ViewEngineConfig.Configure();

        AreaRegistration.RegisterAllAreas();

        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

    }

Using WebActivator goes against this practice and also added another dependency to your project. Technically, your SimpleInjectorIntializer class can be re-written to use the above paradigm and then remove the need for WebActivator.

What do you think?

New Post: Simple Injector - Why and where does it loose points?

dot_NET_Junkie — Wed, 08 May 2013 10:46:58 GMT

Hi Rod,

Simplicity is one of the main goals of Simple Injector and Simple Injector tries to make it easier for developers to start with Dependency Injection. The feature set of Simple Injector is deliberately stripped and with that it tries to push developres in a certain direction that we feel is best; results in the most maintainable software. This doesn't mean that it is limited in its possibilities, but makes forces you to do a bit more work to get certain behavior. Take for instance making registrations with by name/key and doing implicit property injection. Both features are possible to implement in Simple Injector, but not supported out-of-the-box (OOTB), because they are abused most of the time and can lead to DI configurations that are hard to verify. We do however provide documentation that explains most scenarios that are not supported OOTB.

Many developers fear the performance of their DI container. In reality most of the time your container´s performance isn´t an issue, but on the other hand, it´s hard to intuitively sense where the performance bottlenecks are and how to solve them. That is something Simple Injector tries to solve. Everything you do OOTB is fast. About as fast as when wiring things by hand (except the constant overhead a call to GetInstance() has, and the one-time performance hit of the initialization phase). This allows developers to stop worrying about the container's performance.

Simple Injector however is is specially designed with a specific type of architecture in mind. Architectures that are based on the SOLID principles, work with generic abstractions, and use decorators to apply crosscutting concerns (take a look here, here, and here for examples of this type of design). Especially the area of using decorators is where other containers lack and where Simple Injector tries to fill a gap. Most containers use a method called interception to apply crosscutting concerns to types, and make it really hard to apply decorators in a way that is maintainable. In our opinion, the use of decorators is much better than using interception, because decorators don´t force you to take a dependency on some interception library, and results in code that is simpler and faster. Simple Injector for instance, makes it very easy to apply (generic) decorators conditionally, based on either a predicate or a generic type constraint.

Unity makes it possible to apply decorators, but when it comes to applying decorators conditionally, this gets really hard in Unity, and will lead to a DI configuration that becomes unmaintanable. Whether or not this is a problem, depends on the size and design of your application, of course.

Of course I´m biased about Simple Injector, and would argue that you can do anything with Simple Injector, but perhaps not OOTB. So things that are supported by Simple Injector OOTB but are in Unity are for instance keyed registration, interception, and handling types with multiple constructors. Simple Injector on the other hand is very fast and has very good support for decorators.

The choice is up to you.

New Post: Simple Injector - Why and where does it loose points?

RBoavida — Wed, 08 May 2013 08:33:56 GMT

Hi,

I must say I was very impressed with the performance benchmarks I've seen out there regarding Simple Injector as well as the documentation you are providing.

I'm looking into DI frameworks for my company's new product and came across SI.

There is already new developments using Unity for Web applications. The natural way would be to go with Unity. The new product is to be a cloud based multi-threaded application with multiple activations per second so completely different picture.

I have two questions that could help me a lot to decide and influence decisions.

1 - What motivated you on developing such a framework considering the existing ones out there? If it was performance I would like to know about that business case
2 - What are the concrete feature limitations on this framework? From what I'm seeing it can do almost everything as Unity.

Tnks in advance,
Rod