Unity Framework

Unity Application Block

	What is this When to use
	Where to use
	How to use

1.      What is Unity Framework?

Unity Application Block is a lightweight, extensible, dependency injection container that supports to build constructor injection method call injection and property injection.

·         It provides simplified object creation

·         It allows developers to specify dependencies at runtime

·         It allows client to store or cache the container. This is especially useful in Asp.Net Web Application where developers can persist the container in the Asp.Net session or application

2.      When to use Unity Framework?

·         This addresses the issues faced by developers engaged in component based software Engineering.

·         Modern applications which uses business objects and components that perform specific tasks or generic tasks within the application.

·         In addition to components that individually addresses crosscutting concerns such as logging, authentication, authorization, caching and exception handling.

·         Loosely coupled design. This will be easier to maintain, Testing

·         Dependency Injection is the key technique for building loosely coupled design. It provides the way to handle dependencies between objects

·         For example, an object that processes customer information may depend on other objects that access the data store, validate the information, and check that the user is authorized to perform updates. Dependency injection techniques can ensure that the customer class correctly instantiates and populates all these objects, especially where the dependencies may be abstract.

The following design patterns defines architectural and development approaches that simplify the process

Before get deep into let’s have some basic idea about ‘Coupling’

Coupling:

Coupling is where one type in depends on other type. Tight coupling occurs when the type of variable is not abstract, and cannot change without changing having to change other code accordingly.

Loosely couple leads to code that is isolated, in the sense that the change in one piece of code is less likely to affect another section of code.

Loosely coupled code set up makes the test easier. Achieving loosely couple can be done through different ways as below

Service Locator

Dependency Injection

Inversion Control Pattern (ICP):

There are two principles of IOC:

• Main classes aggregating other classes should not depend on the direct implementation of the aggregated classes. Both the classes should depend on abstraction. So the customer class should not depend directly on the address class. Both address and customer class should depend on an abstraction either using interface or abstract class.
• Abstraction should not depend on details, details should depend on abstraction.
   

Figure: - IOC framework

Figure ‘IOC framework’ shows how we can achieve this decoupling. The simplest way would be to expose a method which allows us to set the object. Let the address object creation be delegated to the IOC framework. IOC framework can be a class, client or some kind of IOC container. So it will be two step procedure IOC framework creates the address object and passes this reference to the customer class.

Ways of implementing IOC

Ok, now we know the problem, let’s try to understand the broader level solution. Let’s look at how we implement the solution for IOC. IOC is implemented using DI (Dependency injection). We have discussed on a broader level about how to inject the dependency in the previous sections. In this section we will dive deeper in to other ways of implementing DI.

 

Figure: - IOC and DI

Figure ‘IOC and DI’ shows how IOC and DI are organized. So we can say IOC is a principle while DI is a way of implementing IOC. In DI we have four broader ways of implementing the same:

• Constructor way
• Exposing setter and getter
• Interface implementation
• Service locator

In the further sections we will walkthrough the same in more detail.

Constructor Methodology

In this methodology we pass the object reference in the constructor itself. So when the client creates the object he passes the object in the constructor while the object is created. This methodology is not suited for client who can only use default constructors.

 

Figure: - Constructor based DI
 

Setter and Getter

This is the most commonly used DI methodology. The dependent objects are exposed through set/get methods of classes. The bad point is because the objects are publicly exposed it breaks the encapsulation rule of object oriented programming.

 

Figure: - Getter and Setter
 

Interface based DI 

In this methodology we implement an interface from the IOC framework. IOC framework will use the interface method to inject the object in the main class. You can see in figure ‘Interface based DI’ we have implemented an interface ‘IAddressDI’ which has a ‘setAddress’ method which sets the address object. This interface is then implemented in the customer class. External client / containers can then use the ‘setAddress’ method to inject the address object in the customer object.

Figure: - Interface based DI
 

Service Locator

The other way to inject dependency is by using service locator. Your main class which will aggregate the child object will use the service locator to obtain instance of the address object. The service locator class does not create instances of the address object, it provides a methodology to register and find the services which will help in creating objects. 

Figure: - Service locator

Implementing the DI

Now that we know the various types of DI to implement IOC. Its time to understand how we can actually implement these DI’s.  

What’s wrong with DI FACTORY?

The first thing which clicks to mind is, can't we achieve all the above things using factory. The main problem is all about one class doing the creational activity of its contained objects which leads to heavy coupling. Introducing factory can solve that to a great extent.

Here are the issues with factory which makes us force to think about some other solutions:

• Everything is hardcoded: - The biggest issues with factory are it can not be reused across applications. All the options are hardcoded in the factory itself which makes the factory stringent to particular implementation.
• Interface dependent: - The base on which factories stands are common interfaces. Interfaces decouple the implementation and the object creation procedure. But then all the classes should implement a common interface. This is a limitation by itself again.
• Factories are custom: - They are very much custom to a particular implementation.
• Everything is compile time: - All dependent objects for an object in factory have to be known at compile time.

The container way

A container is an abstraction responsible for object management, instantiation and configuration. So you can configure the objects using the container rather than writing client code like factory patterns to implement object management. There are many containers available which can help us manage dependency injection with ease. So rather than writing huge factory codes container identifies the object dependencies and creates and injects them in appropriate objects. 

Figure: - Container in action

So you can think about container as a mid man who will register address and customer objects as separate entity and later the container creates the customer and address object and injects the address object in the customer. So you can visualize the high level of abstraction provided by containers.

What we will do is cover the customer and address example using one of the container Windsor container, you can get more details about the container here.

Implementation using Windsor

The first thing we do is create the address interface and create the concrete class from this interface. Interface will be an entity to use for injection rather than concrete objects, so that we deal with more abstraction rather than concrete implementation. 

Figure: - Address interface

In the customer class we have passed the object through the constructor.

Figure: - Customer class

If we are said to write the client code. , it would be something as shown in figure ‘Client code’. In step 1 we create a concrete object and point the implementation to the interface IAddress. In step 2 we pass the interface object to customer class constructor while creating the object.