Unity Container

If you just read my page on Dependency Injection you may be asking yourself...

Why use a Unity container instead of a factory?

There are a lot of reasons why you might consider using containers in your application instead of factories, not the least of which is that Factories are Type specific. Factories produce related types of objects while Containers can hold more than one type of object or service or a combination of both.

Configuration: A container’s services can be created either declaratively (via configuration files) or .Net base attributes. Your consuming Objects don’t need any knowlede of how to construct services.

The number types is often hardwired into Factories while Containers can produce any number of different types.

Containers provide services which can be used across various applications in an enterprise without having to embed specific loging into an applciation. In .Net, for instace, the way containers can manage lifetimes for you, enables you to create your containers on Application start and make them available application wide.

Unit Testing. The loose coupling is ideal for unit testing, if you use composition in your programming model, you have the option of creating test containers with Mock data which your objects can execute against instead of depending on hitting production systems..



Unity Container Example:

Creating a basic unity container is quite simple, you need the Class that you want to create and the Interface it provides. In this case we want our unity container to hold a FooModel. FooModel has provided several public methods to us through the IfooModel interface. Creating our unity container goes something like the example below.

///

/// Handles the initialization of the test cases.

///

[TestInitialize]

public void Init()

{



IUnityContainer container = new UnityContainer()

.RegisterType();



this.unityContainer = container;

this.model = this.unityContainer.Resolve();

}

The example above will be available to each of the test methods in our test class.





Say however that we want our container to manage a singleton for us and the FooModel now takes a dependency on the constructor. The example below will turn our FooModel into a singleton and will handle injecting dependencies for us.

///

/// Handles the initialization of the test cases.

///

[TestInitialize]

public void Init()

{

/// Makes FooModel a singleton

IUnityContainer container = new UnityContainer()

.RegisterType(new ContainerControlledLifetimeManager());



/// Inject a FooDependencyObject.

container.Configure()

.ConfigureInjectionFor(new InjectionConstructor(new FooDependencyObject()));



this.unityContainer = container;

this.model = this.unityContainer.Resolve();

}



Simple and you can see that the .Resolve method will produce our Foo Singleton.


Simple and you can see that the .Resolve method will produce our Foo Singleton.

There are two types of lifetime managers, ContainerControlledLifetimeManager and ExternallyControlledLifetimeManager.

ContainerControlledLifetimeManager will implement a singleton, returning the same instance of the object each time you call .Resolve or .ResolveAll

ExternallyControlledLifetimeManager will return the same instance of the object, however the container holds a “weak reference” to the object. Basically, the object is subject to garbage collection when it goes out of scope.

If you don’t name a lifetime manager, you will get a new object each time.