2010 18 Apr
In this world of technology crises, the main challenge for software architects and developers is to build extensible applications that can live and respond to requirements changes. Loosely coupled components is a main issue in building such application, as well as enhancing the main software engineering concepts as structure, testability, maintainability and extensibility.
To focus more at the problem let’s check the following software development case; supposing that we have two classes Person and Address, each person has and address. The first implementation for such example simple as:

class Address
{
}
class Person
{
private Address _address;
public Person()
{
_address = new Address();
}
}
The biggest problem with the above code is the tight coupling between the two classes; you can see clearly that the class Person depends of the class Address and should be recompiled whenever the class Address changes. In addition if the Person class fails to create an instance of the address class, it will fail to be created.
Clearly we have a design problem here; to solve it we need a set of rules and guidelines, this is what a design pattern does.
The main goal of the proposed solution should shift the creation of the Address object to someone else than the Person object, the solution name is the Inversion of Control.
The Inversion of Control abbreviated IoC stands on the principle of “don’t call me – I’ll call you” (in Lebanese: ma tdeilli – ana bdeilak), this will be clearly seen in the above example as the Address object will say to the Person class: Do not create me, I’ll find somebody else to create me.

IoC is like a concept and needing an implementation; the Dependency Injection is responsible to do the implementation of the IoC, and there are four ways to do it:
- Constructor way
The object is passed by reference to the constructor, so the address object is created somewhere outside the constructor of the person class and then passes by parameter.
class Person
{
private Address _address;
public Person(Address address)
{
_address = address;
}
}
- Exposing setter and getter
The dependent objects are exposed using methods in the constructor.
class Person
{
private IAddress _address;
public IAddress Address
{
get { return _address; }
set { _address = value; }
}
public Person()
{
}
}
- Interface implementation
The constructor class implements an interface from the IoC framework.
internal interface IAddressDI
{
void SetAddress(IAddress address);
}
class Person : IAddressDI
{
private IAddress _address;
public Person()
{
}
public void SetAddress(IAddress address)
{
_address = address;
}
}
- Service Locator
This is widely used between software developers; it consists of the creation of a service locator class, accessible from all the other classes, used to get an instance of a selected type and to inject its dependencies. It provides a methodology to register and find the services which will help in the creation of objects.
This locator plays the role of a factory class.
public static class AddressLocator
{
public static IAddress GetAddress()
{
return new Address();
}
}
internal class Person
{
private IAddress _address;
public Person()
{
_address = AddressLocator.GetAddress();
}
}
These dependencies need to be managed as well as the objects creation and lifetime; this can be configured by an abstraction responsible of doing it. There are many solutions for this issue; one of these solutions is the container. The container in our solution will simply create a Person and an address and injects the dependency.
The container can be chosen based on the developer point of view and experience, I would choose the Composite Unity Block included in the Enterprise Library to do the work for me.
It was a pleasure for me to present the IoC and DI in a session for ArabiaGIS and ACT teams in Beirut, the PowerPoint file is published at my slideshare profile, and can be accessed by clicking here.
Thank you, mbote.
what do think about Unity ? is unity a good choice to implement the DI ?
Yeah Dani, Unity is my choice, as you know there are alot of dependency injection container, for many reasons i would choose the Unity- check out why: http://www.jaftalks.com/Home/Show/Unity-Application-Block



