In this post I will show you how to use Microsoft Unit Application Block to achieve Dependency Injection. We will see the two methods of configuring the IOC container, firstly the “.config” way and then the “inline” method. Let us take a look at the following code snippet and see how this code can be improved.
class Program
{
static void Main(string[] args)
{
Service svc = new Service();
svc.Print();
}
}
public class Service
{
public void Print()
{
Employee empl = new Employee();
empl.PrintEmployeeTitle("Test Employee");
}
}
public class Employee
{
public void PrintEmployeeTitle(string name)
{
Console.WriteLine("Employee Name: {0}, Title:{1}", name, "Some Title");
}
}
What does this code do?
The above code snippet if from a console application, where we are creating an instance of the Service class and are calling the Print method. The Print method in turn instantiates the Employee class and then calls the PrintEmployeeTitle method of the Employee class to print the employee name and title. The PrintEmployeeTitle method writes the name and title of an employee to the console.
What is wrong?
Nothing. While there is nothing wrong with this code, if we closely observer, we can notice that the Employee class instance could not exist without an instance of the Service class. Basically they both are tightly coupled, meaning to say we can only have one implementation of the Employee class to be consumed by the Service class at any given instance of time.
What if we have a scenario when we want to test more than one implementation of the Employee class or if the Employee class implementation is a work-in-progress? Here is where Dependency Injection design pattern comes to our rescue. I hope I have set some context before I explaining about DI and its implementation.
Solving the problem
Decoupling the Employee class life cycle management from the Service class is the primary objective. The advantage of decoupling the Employee class are that 1) we will be in a position to provide multiple implementations to the Employee class 2) be able to select the kind of implementation that is suitable for our purpose and 3) manage the life cycle of the Employee class. We define an interface IEmployee with one method PrintEmployeeTitle and define two implementations for this demo purpose. The first implementation is what we already had above and the second is a MockEmployee Class.
public class Employee : IEmployee
{
public void PrintEmployeeTitle(string name)
{
Console.WriteLine("Employee Name: {0}, Title:{1}", name, "Some Title");
}
}
public class MockEmployee : IEmployee
{
public void PrintEmployeeTitle(string name)
{
Console.WriteLine("Employee Name: {0}, Title:{1}", name, "Some MOCK Title");
}
}
public interface IEmployee
{
void PrintEmployeeTitle(string name);
}
Let us see how we can delegate the Employee class instantiation to the client (Class:Program; Method: Main) and then inject the Employee object into the Service object.
Dependency Injection
Service class has a dependency on the Employee class and our objective here is inject this dependency into the Service class from the Client. Dependency injection is a software design pattern that allows a choice of component to be made at run-time rather than compile time [2]. One way to achieve this is via passing the Employee object reference to the Service class constructor like in the code below:
class Program
{
static void Main(string[] args)
{
Employee empl = new Employee();
Service svc = new Service(empl);
svc.Print();
}
}
public class Service
{
private IEmployee empl;
public Service(IEmployee empl)
{
this.empl = empl;
}
public void Print()
{
empl.PrintEmployeeTitle("Test Employee");
}
}
Another way of injecting the Employee reference into the Service object is via setting the instance of Employee class to an I IEmployee property of the Service class.
class Program
{
static void Main(string[] args)
{
Employee empl = new Employee();
Service svc = new Service();
svc.empl = empl;
svc.Print();
}
}
public class Service
{
IEmployee _empl;
public IEmployee empl
{
set
{
this._empl = value;
}
}
public void Print()
{
_empl.PrintEmployeeTitle("Test Employee");
}
}
We have so far been able to decouple the Service class and the Employee class, however we still have to create an instance of the Employee class to implement dependency injection. Any change in to the Employee class creation mechanism with require a code change and also a code recompile. This is the point where IOC framework comes handy in automating the creation and injection of the dependency via just one configuration.
Inversion of control
In software engineering, Inversion of Control (IoC) is an object-oriented programming practice where the object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis [1]. Like discussed earlier we are going to transfer the control of creating the Employee object to the IOC framework rather than keeping it with the Client, mean to say we are performing an “Inversion of Control”.
The configured entities are loaded into an IOC container at run-time and will be injected into the appropriate classes. We can implement .Net Dependency Inject using any one of the following IOC containers:
Microsoft Unity IoC Container
Now let us look at the two ways of configuring and implementing DI using Microsoft Unity Container. Before we can use the Unity container you have to download and install the Microsoft Unit Application Block from the Microsoft Patterns and Practices website. The dll’s necessary for this implementation can be found under the “Drive:/Program Files/Microsoft Unity Application Block x.0/Bin/” folder and should be added as references to your project.
Please accept my apologies for a very crude/rude representation of the client (Class: Program, Method: Main) being able to select one of the three implementations of the Employee class use Dependency Injection via an IOC container.
Application Configuration File
When we have to implement DI using the Application Config file, we have to define Unity block section, define a container and register that namespace and the Class that is getting DI’ed.
<configSections>
<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,Microsoft.Practices.Unity.Configuration" />
</configSections>
<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<alias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,
Microsoft.Practices.Unity" />
<container name="TestService">
<register type="UnityFrameworkDemo.IEmployee, UnityFrameworkDemo"
mapTo="UnityFrameworkDemo.MockEmployee, UnityFrameworkDemo">
<lifetime type="singleton" />
</register>
</container>
</unity>
I had to also add a reference of the System.Configuration namespace to the project. Once we have this configuration all set, we have to update the client to 1) load the container that we defined in the configuration and 2) generate the Service class based on the configuration that we have defined:
class Program
{
static void Main(string[] args)
{
try
{
container.LoadConfiguration("TestService");
svc = container.Resolve();
if (svc != null)
svc.Print();
else
Console.WriteLine("Could not load the Service Class");
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
public class Service
{
IEmployee _empl;
public Service(IEmployee empl)
{
this._empl = empl;
}
public void Print()
{
_empl.PrintEmployeeTitle("Test Employee");
}
}
You would also have noticed that I have added a constructor that accepts parameter of IEmployee type to the Service class. The IOC framework will use this constructor to generate an instance of the Service class and will also pass a reference of the Employee class into the Service instance. Following is the output of using the default Employee implementation:
Now switching to the Mock Employee implementation from the default implementaion is as simple as updating the register element of the configuration with the MockEmployee class name and then we get the following output
Inline
Lastly let us look at how we can configure an implementation inside the client instead of in the application config file. Basically you have to register the Interface and the implementation with the container in the client and your client is ready to make a call to the Service instance methods like shown in the code below:
container.RegisterType();
svc = container.Resolve();
if (svc != null)
svc.Print();
Unity framework basically provides a fantastic approach to decouple the application layer code. You can define several containers and register several classes with the container and be able to enjoy the flexibility by implementing Dependency Injection using the Unity IOC container.
Happy Fourth of July !
References:
1. Inversion of Control – IOC – Wikipedia
2. Dependency Injection – Wikipedia
Caveman's Blog 