Lazy Instantiation with Unity Application Block

Configuring the Unity Application Block for just-in-time Instantiation. 

Out of the box, Unity does not provide a way to configure your dependencies so that they are resolved only if needed.  Lazy Instantiation would be desirable if your dependency is and required only under certain circumstances or you would like to delay object creation of a resource intensive dependency until needed.

For Lazy Instantiation, the first obstacle to overcome when using IoC Containers like Unity, is to have your components get a reference to the container so the dependency creation can be delegated to it when the need arises.  My first inclination was to wrap Unity in a Singleton and have the component reference this in order to resolve the dependency. 

Container.Instance.Resolve<IProductService>();

Singleton’s are, however, notoriously difficult to test and very rigid in design.  Used in this manner,  a Singleton is nothing more than a global variable wrapped in a buzzword.  so I wanted a different approach.  Since we are using a Dependency Injection Framework, why not have the container inject a reference to itself into our components.

1.  First, configure the Unity container so that it can return a reference to itself.

2.  Next, create a property on your class to get a reference to the Unity container that created it.

3.  Finally, have the container resolve the dependency the first time it’s referenced. 

Unit Testing

Testing is straight forward as well.   You could have your unit test use reflection to reach in and set the private field (_productService) to your mock object.  However,  giving your Unit Tests access to private members violates the “Use the Front Door First” Test Automation Principle and should be avoided if possible.  Alternatively, you could create a mock object for IUnityContainer and have it return a mock object for IProductService when the Resolve method is called.

Using RhinoMocks, the Unit Test would look something like this:

Bookmark It