Unity – Dependency Injection and Inversion of Control Container

The Dependency Injection Pattern
Dependency injection is a programming technique to reduce component coupling. Dependency injection is also commonly known as “inversion of control” or IoC or sometimes as The Hollywood Principle – "Don’t call us, we’ll call you”. The goal of dependency injection is to separate the concerns of how a dependency is obtained from the core concerns of a boundary. This improves reusability by enabling components to be supplied with dependencies which may vary depending on context.

The Old Way
Following is an example of how you might write code if not using dependency injection

public class WebApp
{
    public WebApp()
    {
        quotes = new StockQuotes();
        authenticator = new Authenticator();
        database = new Database();
        logger = new Logger();
        errorHandler = new ErrorHandler();
    }
} 

Problem

• What about the child objects?
• How does the StockQuotes find the Logger?
• How does the Authenticator find the database?
• Suppose you want to use a TestingLogger instead? Or a MockDatabase?

Service Locator pattern attempts to solve some of the problems mentioned above by providing a dictionary of objects. The objects are all stored in this dictionary and the Get method simply returns the object to the caller.

Service Locator Example

public interface ILocator
{
    TObject Get<TObject>();
}
public class MyLocator : ILocator
{
    protected Dictionary<Type, object> dict = new Dictionary<Type,object>();
    public MyLocator()
    {
        dict.Add(typeof(ILogger), new Logger());
        dict.Add(typeof(IErrorHandler), new ErrorHandler(this));
        dict.Add(typeof(IQuotes), new StockQuotes(this));
        dict.Add(typeof(IDatabase), new Database(this));
        dict.Add(typeof(IAuthenticator), new Authenticator(this));
        dict.Add(typeof(WebApp), new WebApp(this));
    }
}
public class StockQuotes
{
    public StockQuotes(ILocator locator)
    {
        errorHandler = locator.Get<IErrorHandler>();
        logger = locator.Get<ILogger>();
    }
} 

Pros

• Classes are decoupled from explicit implementation types
• Easy to externalize the config

Cons

• Everyone takes a dependency on the ILocator
• Hard to store constants and other useful primitives
• Creation order is still a problem

Dependency Injection Containers
The dependency injection container is a component responsible for assigning dependencies to a recipient component. Containers are generally implemented using the Factory Pattern to allow creation of the recipient and dependency components. Containers are often implemented to allow existing objects to be registered for use as a dependency, or to create new instances when required. Using a dependency injection container with our StockQuotes example provides the following benefits:

• Gets rid of the dependency on the ILocator
• Object is no longer responsible for finding its dependencies
• The container does it for you

In a nutshell, dependency injection just means that a given class or system is no longer responsible for instantiating their own dependencies. In this case “Inversion of Control” refers to moving the responsibility for locating and attaching dependency objects to another class or a DI tool. That might not sound that terribly profound, but it opens the door for a lot of interesting scenarios.
Benefits of Dependency Injection:

• Dependency Injection is an important pattern for creating classes that are easier to unit test in isolation
• Promotes loose coupling between classes and subsystems
• Adds potential flexibility to a codebase for future changes
• Can enable better code reuse

Unity Application Block
Unity Application Block is a lightweight Inversion of Control container which supports constructor, property and method call injection. Unity sits on top of another framework called ObjectBuilder, but is different from the ObjectBuilder which has been a part of Enterprise Library 3.1 and earlier. Unity is based on v2 of the Objectbuilder and has been optimized for performance quite a bit. Unity is available both as a standalone and part of Enterprise Library 4.0 on codeplex at http://www.codeplex.com/unity and http://www.codeplex.com/entlib. Unity 1.1 is not part of Enterprise Library 4.0 but the good thing about it is that it will update the Unity dlls/libraries in Enterprise Library 4.0 installed folder to 1.1 during installation.

The Unity Application Block includes the following features:

• It provides a mechanism for building (or assembling) instances of objects, which may contain other dependent object instances.
• It exposes RegisterType methods that support configuring the container with type mappings and objects (including singleton instances) and Resolve methods that return instances of built objects that can contain any dependent objects.
• It provides inversion of control (IoC) functionality by allowing injection of preconfigured objects into classes built by the application block. Developers can specify an interface or class type in the constructor (constructor injection), or apply attributes to properties and methods to initiate property injection and method call injection.
• It supports a hierarchy for containers. A container may have child container(s), allowing object location queries to pass from the child out through the parent container(s).
• It can read configuration information from standard configuration systems, such as XML files, and use it to configure the container.
• It makes no demands on the object class definition. There is no requirement to apply attributes to classes (except when using property or method call injection), and there are no limitations on the class declaration.
• It supports custom container extensions that developers can implement; for example, methods to allow additional object construction and container features such as caching.

Unity has no dependency on Enterprise Library core and can be used without having to install Enterprise Library on the host system. To use Unity in your application you need to add reference to the following dlls in your project
    Microsoft.Practices.ObjectBuilder2
    Microsoft.Practices.Unity

The Unity container can be configured through configuration files or you can use code to register dependencies dynamically at run time. To use Unity with configuration files you need to add reference to the following dll
    Microsoft.Practices.Unity.Configuration

Steps when using Dependency Injection

• Write your objects the way you want
• Setup the container
• Ask the container for objects
• The container creates objects for you and fulfills dependencies

Setup the container
The ideal place to setup the Unity container for ASP.NET applications is in the Application_Start method of the global.asax file. We would like to have a persistent container that hold it’s state during the execution of the application. The right place to put this is in the Global.asax file as a property of the current application.

We create a simple interface for the container property so that we can access our container using this interface

public interface IContainerAccessor
{
    IUnityContainer Container { get; }
}

class in the Global.asax file:

private static UnityContainer _container;
public static UnityContainer Container
{
    get
    {
        return _container;
    }
    set
    {
        _container = value;
    }
}
protected void Application_Start(object sender, EventArgs e)
{
    BuildContainer();
}
protected void Application_End(object sender, EventArgs e)
{
    CleanUp();
}
private static void BuildContainer()
{
    IUnityContainer container = new UnityContainer();
    //TODO: Register the relevant types for the container here through classes or configuration
    Container = container;
}
private static void CleanUp()
{
    if (Container != null)
    {
        Container.Dispose();
    }
} 

The BuildContainer method is where we will setup our container and register our types for dependency injection. The RegisterType<TFrom, TTo>() method tells Unity that whenever someone asks for a dependency on TFrom give them Tto. In the example code below the statement container.RegisterType<ILogger, EventLogLogger>() tells Unity that whenever someone has a dependency on type ILogger go ahead and create an object of type EventLogLogger.

There are a couple of different flavors of Dependency Injection

• Constructor Injection – Attach the dependencies through a constructor function at object creation
• Setter Injection – Attach the dependencies through setter properties
• Service Locator – Use a well known class that knows how to retrieve and create dependencies. Not technically DI, but this is what most DI/IoC container tools really do

Constructor Injection

public interface ILogger
{
    void LogEvent(string message);
}
public class FileLogger : ILogger
{
    public void LogEvent(string message)
    {
        ...
    }
}
public class EventLogLogger : ILogger
{
    public void LogEvent(string message)
    {
        ...
    }
}
public class StockQuotes
{
    private Ilogger _logger;
    public class StockQuotes(ILogger logger)
    {
        _logger = logger;
    }
} 

UnityContainer container = new UnityContainer();
...
contianer.RegisterType<ILogger, EventLogLogger>();
StockQuotes quotes = container.Resolve<StockQuotes>(); 

If a class that developers instantiate using the Resolve method of the Unity container has a constructor that defines one or more dependencies on other classes, the Unity container will automatically create the dependent object instance specified in parameters of the constructor. In the above example StockQuotes has a dependency on ILogger. When we create an instance of the StockQuotes class using the Resolve method of the Unity container, Unity will automatically create an instance of EventLogLogger and pass it to the constructor of StockQuotes class.

The benefit of using constructor injection is that the constructor function now explicitly declares the dependencies of a class. Constructor injection is often recommended as it eliminates chatty calls to the object and creates a valid object in as few steps as possible.

Setter Injection

public class OracleDatabase : IDatabase
{
    Public void ExecuteQuery(string query)
    {
        ...
    }
}
public class SqlDatabase : IDatabase
{
    public void ExecuteQuery(string query)
    {
        ...
    }
}
public class Authenticator
{
    private IDatabase _database;
    [Dependency]
    public IDatabase DB
    {
        get{return _database;}
        set{_database = value;}
    }
} 

UnityContainer container = new UnityContainer();
...
contianer.RegisterType<IDatabase, SqlDatabase>();
Authenticator auth = container.Resolve<Authenticator>(); 

To force dependency injection of the dependent object, developers must apply the [Dependency] attribute to the property declaration. Many would argue that setter injection is really useful when legacy code needs to be upgraded and provides a smooth transition from legacy code to the new model. Making sure that any new code that depends on undesirable legacy code uses Dependency Injection leaves an easier migration path to eliminate the legacy code later with all new code. 

As a service locator

UnityContainer container = new UnityContainer();
contianer.RegisterType<ILogger, NullLogger>();
…
ILogger logger = container.Resolve<ILogger>(); 

Here we are just telling unity to give us the ILogger interface which is already registered with the container. Using the container in this manner makes it a service locator.

Unity Dependency injection provides a number of ways to configure the container. As described above you use the RegisterType method to inform the container about dependencies. But Unity can also manage the object lifetime e.g.

Dependencies as singleton

UnityContainer container = new UnityContainer();
container.RegisterType<Database, SqlDatabase>(new ContainerControlledLifetimeManager()); 

The above code  tells Unity that whenever someone asks for type Database give them type SqlDatabase and return the same object every time instead of creating a new one for each dependency.

Named Instance

UnityContainer container = new UnityContainer();
contianer.RegisterType<Database, SqlDatabase>("SQL");
container.RegisterType<Database, OracleDatabase>("Oracle");
IEnumerable<Database> databases = container.ResolveAll<Database>();
Database database = container.Resolve<Database>("SQL"); 

Named instance allows you to configure Unity with multiple dependencies for the same type but assign them different names. Thi s allows you to do fancy stuff where you want a default type mapping but also want to override the mapping by providing a name during object creation.

Registering an existing object instance
So far all the examples above show how a type can be registered with Unity and the Unity container creates the object for you whenever requested. But what if you already have the object created and want to register this object in Unity.

UnityContainer container = new UnityContainer();
contianer,RegisterInstance<Database>(new SqlDatabase());
contianer.RegisterInstance<Database>("Oracle", new OracleDatabase());
Database database = container.Resolve<Database>();
Database oracleDatabase = container.Resolve<Database>("Oracle"); 

When using RegisterIntance Unity will automatically make the objects singletons.

Configuring Unity via config file
The Unity container can be configured through configuration files. To use Unity with configuration files you need to add reference to the following dll
    Microsoft.Practices.Unity.Configuration

Use following code to read the container setup from configuration file:

UnityContainer container = new UnityContainer();
UnityConfgurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
Section.Containers.Default.GetConfigCommand().Configure();
ILogger logger = container.Resolve<ILogger>(); 

.config file:

<configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
</configSections>
<unity>
    <typeAliases>
    <!-- Lifetime manager types -->
    <typeAlias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,Microsoft.Practices.Unity" />
    <typeAlias alias="external" type="Microsoft.Practices.Unity.ExternallyControlledLifetimeManager,Microsoft.Practices.Unity" />
    </typeAliases>
    <containers>
        <container>
            <types>
                <type type="ConsoleApplication1.Database, ConsoleApplication1" mapTo="ConsoleApplication1.SqlDatabase, ConsoleApplication1" lifetime="Singleton" />
                <type type="ConsoleApplication1.ILogger, ConsoleApplication1" mapTo="ConsoleApplication1.EvnetLogLogger, ConsoleApplication1" lifetime="Singleton" />
            </types>
        </container>
    </containers>
</unity> 

Nested Containers
Unity supports nested containers, which allows the parent container to create child containers. This provides the ability to override parent type mappings with child type mappings. Parent-Child relationship between Unity containers. What this means is that the parent-child relationship between Unity containers will search the child container to the resolve the type mapping, and if not found, will navigate up to the parent container to resolve the type.

UnityContainer parentContainer = new UnityContainer();
IUnityContainer childContainer1 = parentContainer.CreateChildContainer();
IUnityContainer childContainer2 = parentContainer.CreateChildContainer(); 

parentContainer.RegisterType<ILogger, FileLogger>(new ContainerControlledLifetimeManager());
childContainer1.RegisterType<ILogger, EventLogLogger>(new ContainerControlledLifetimeManager()); 

ILogger logger = childContainer2.Resolve<ILogger>(); // should return FileLogger from parentContainer
ILogger logger2 = childContainer1.Resolve<ILogger>(); //should return EventLogLogger from childContainer1 

While registering types with Unity there is a certain risk of introducing unintentional circular references, which are not easy to detect or prevent.
For example, the following code shows two classes that reference each other in their constructors.

public class Class1
{
  public Class1(Class2 test2)
  { ... }
} 

public class Class2
{
  public Class2(Class1 test1)
  { ... }
} 

It is the responsibility of the developer to prevent this type of error by ensuring that the members of classes they use with dependency injection do not contain circular references.

References

• Martin Fowler on Inversion of Control and the Dependency Injection Pattern
• David Hayden’s screen cast on Unity.
• Gil Fink on How to use Unity Container in ASP.NET
• Jeremy D. Miller on Dependency Injection Pattern

Technorati Tags: Unity,Dependency Injection,Inversion of Control