As you know, we always define an interface to abastract a service provided by the different concrete classes. In the following example, we define an interface named IInvoice to present the general invoice services proivded by the invoices A and B. To simplify the example, we just declare the Title property in the interface:

public interface IInvoice
{
    string Title
    {
        get;
    }
}

class InvoiceA : IInvoice
{
    public InvoiceA()
    {
    }

    public string Title
    {
        get
        {
            return "Invoice A";
        }
    }
}

class InvoiceB : IInvoice
{
    public InvoiceB()
    {
    }

    public string Title
    {
        get
        {
            return "Invoice B";
        }
    }
}

We also define an InvoiceManager class to represent all kinds of invoice operation, such as issue an invoice.

class InvoiceManager
{
    private IInvoice _invoice;

    public InvoiceManager(IInvoice invoice)
    {

        _invoice = invoice;

    }

    public void IssueInvoice()
    {
        Console.WriteLine(this._invoice.Title);
    }
}

Please note that we are using the IInvoice interface instead of concrete class in the above code to facilitate operate different voices uniformly. For example, if you want to issue an invoice A, you can do it like:

InvoiceManager invoiceMgr = new InvoiceManager(new InvoiceA());

invoiceMgr.IssueInvoice();

Next time, if you want to issue an invoice B, you can do it:

InvoiceManager invoiceMgr = new InvoiceManager(new InvoiceB());

invoiceMgr.IssueInvoice();

The following figure illustrate the dependecies among the three entities.

The InvoiceManager class is dependent on the IInvoice interface and upon both the implementations, that means the InvoideManager has to know what invoice to issue at compile time.

We would prefer it if it were only dependent on the interface shown in the following figure, but then how do we make an instance to work with?

Let's rewrite code to demonstrate how to use the Unity Container mechanism:

1. Create a new console project called DIConsoleDemo

2. Add references to the following assemblies:

• System.Configuration
• Microsoft.Practices.Unity
• Microsoft.Practices.Unity.Configuration

3. Create 4 types

namespace DIConsoleDemo
{
    public interface IInvoice
    {
        string Title
        {
            get;
        }
    }
}

namespace DIConsoleDemo
{
    class InvoiceA : IInvoice
    {
        public InvoiceA()
        {
        }

        public string Title
        {
            get
            {
                return "Invoice A";
            }
        }
    }
}

namespace DIConsoleDemo
{
    class InvoiceB : IInvoice
    {
        public InvoiceB()
        {
        }

        public string Title
        {
            get
            {
                return "Invoice B";
            }
        }
    }
}


namespace DIConsoleDemo
{
    class InvoiceManager
    {
        private IInvoice _invoice;

        public InvoiceManager(IInvoice invoice)
        {

            _invoice = invoice;

        }

        public void IssueInvoice()
        {
            Console.WriteLine(this._invoice.Title);
        }

    }
}

4. Create the application configuration file (App.config):

<?xml version="1.0" encoding="utf-8" ?>

<configuration>
  <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
  </configSections>
  <unity>
    <typeAliases>
      <typeAlias alias="IInvoice" type="DIConsoleDemo.IInvoice, DIConsoleDemo" />
      <typeAlias alias="InvoiceA" type="DIConsoleDemo.InvoiceA, DIConsoleDemo" />
      <typeAlias alias="InvoiceB" type="DIConsoleDemo.InvoiceB, DIConsoleDemo" />
    </typeAliases>
    <containers>
      <container>
        <types>
          <type type ="IInvoice" mapTo="InvoiceA">
          </type>
        </types>
      </container>
    </containers>
  </unity>
</configuration>

5. In the main() method, add the following code:

using System.Configuration;

using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;

namespace DIConsoleDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();

            UnityConfigurationSection section =(UnityConfigurationSection)ConfigurationManager.GetSection("unity");

            section.Containers.Default.Configure(container);

            InvoiceManager invoiceMgr = container.Resolve<InvoiceManager>();

            invoiceMgr.IssueInvoice();
        }
    }
}

6. Run the proejct and see the result:

Invoice A

7. If you change the type mapping in the configuration file:

<type type ="IInvoice" mapTo="InvoiceB">

and run the proejct again, you will see the result:

Invoice B

That's it. To decouple the dependency, whenever you want an object, you have to use the container to create the instance using container.Resolve<T>() method instead of the "new" keyword. Although the InvoiceManager class is not configured in the App.config file, it is still participating in Dependency Injection. When asked to resolve the type InvoiceManager, the UnityContainer did not find any mapping to use to substitute InvoiceManager by something else. However, the UnityContainer analyzed the constructor of InvoiceManager and found that InvoiceManager has a dependency on IInvoice. So the UnityContainer resolved IInvoice into an InvoiceA based the mapping and then passed it to the InvoiceManager constructor.

Lifetime management in Unity

The UnityContainer is able to manage the lifetime of the objects it resolves. By default, the UnityContainer creates a new instance of any type it resolves. You can prove this with this unit test:

There are 4 basic options for lifetime management:

1. No management: The container does not keep a reference on the objects it creates and therefore creates a new object each time Resolve<T>() is called.
2. Singleton: The container always returns the same instance
3. Singleton-per-thread: The container keeps one instance for each thread and return the instance based on the current thread.
4. Externally controlled: You provide a class that will manage the instances. This option is not covered in this article.

The configuration of lifetime management is done at the <type> level. Each lifetime management option is supported by one type (class) in the unity application block library.

For example, the class ContainerControlledLifetimeManager is the class that implements the "singleton" lifetime management style.

- To resolve the IInvoice type using a singleton, change the <type> section this way:

<type type ="IInvoice" mapTo="InvoiceA">

    <lifetime type= "Microsoft.Practices.Unity.ContainerControlledLifetimeManager, Microsoft.Practices.Unity" />

</type>

Using the fully qualified name for the ContainerControlledLifetimeManager class can make files hard to read. The configuration section for unity supports defining aliases. The aliases can then be used anywhere a type name is expected. I recommend defining 3 aliases for the 3 types of lifetime management option.

Inside the <unity> section (but above and outside the <containers> sections, add the following alias definitions:

<typeAliases>

    <typeAlias alias="singleton"

        type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager, Microsoft.Practices.Unity" />

    <typeAlias alias="perThread"

        type="Microsoft.Practices.Unity.PerThreadLifetimeManager, Microsoft.Practices.Unity" />

    <typeAlias alias="external"

        type="Microsoft.Practices.Unity.ExternallyControlledLifetimeManager, Microsoft.Practices.Unity" />

</typeAliases>

- You can now simplify the <type> declaration for IInvoice this way:

<type type ="IInvoice" mapTo="InvoiceA">
 <lifetime type="singleton" />
</type>

If you delcare singleton for IInvoice, then the above will not throw any exception anymore.

You can also specify a lifetime for type that does not have a mapping. In this case, add a <type> section for that type but do not add a mapTo attribute. Then add the <lifetime> element to that type.