Inversion of Control

The purpose of IOC is to build loosely coupled software architecture.

To understand the need of loosely coupled architecture, let me explain the problem with tight coupling.

Consider following example:

Consider following class of Employee

public class Employee

    {

        int empNo;

        string empName;

        Address empAddress;

        public Employee()

        {

            empAddress = new Address();

        }

    }

The problem here is that Employee and Address classes are tightly coupled with each other.

Any change in Address class will affect Employee class implementation and will require change in Employee class.

Employee class is aware of the address class. So if we add new address types like home address, office address etc it will require change in customer class.

Here we say class Employee has dependency on class Address.

This situation has the following problems:

• To replace or update the dependencies, we need to change our class’s source code.
• The concrete implementations of the dependencies have to be available at compile time.
• Our classes are difficult to test in isolation because they have direct references to dependencies
• Our classes contain repetitive code for creating, locating, and managing their dependencies.

Solution to this problem is to decouple the classes and Delegate the task of managing the dependencies to external component.

In other words we have to invert the control of creating dependencies to a third party.

Any of the following conditions justifies using the solution described in this pattern:

• You want to decouple your classes from their dependencies so that the dependencies can be replaced or updated with minimal or no changes to your classes' source code.
• You want to write classes that depend on classes whose concrete implementations are not known at compile time.
• You want to test your classes in isolation, without using the dependencies.
• You want to decouple your classes from being responsible for locating and managing the lifetime of dependencies.

IOC can be implemented in several ways. The Dependency Injection pattern and the Service Locator pattern are specialized versions of this pattern.

Dependency Injection using Windsor container

Here I am explaining Dependency Injection using Windsor container.

Typically, you express dependencies on interfaces instead of concrete classes. This enables easy replacement of the dependency concrete implementation without modifying your classes' source code.

To create loose coupling we will Create a interface IAddress and create a concreate class Address from this interface. 

We will pass the object of IAdress to Employee class constructor and hence if we have to add a new class as HomeAddress we will create a new class HomeAddress implementing IAdress interface and there will be no need to change the code in Employee class.

public class Employee

    {

        int empNo;

        string empName;

        IAddress empAddress;

        public Employee(IAddress address)

        {

            this.empAddress = address;

        }

    }

public interface IAddress

    {

    }

    public class Address : IAddress

    {

        public string address;

        public string city;

        public string state;

        public Address()

        {

            this.address = "Default Address";

            this.city = "Default City";

            this.state = "Default State";

        }

    }

Now here in this example class Employee have dependency on class Address and if we were to create object of class Employee without using Dependency Injection we will have to manually create objects of all dependencies (in this case Address class object) and pass it to Employee class creation as follows:

/* Manually Creating Dependency object i.e.Address and passing it while creating Employee object */

            Address address = new Address() { address = "M.G.Road", city = "Shirur", state = "Maharashtra" };

            Employee emp = new Employee(address);

Using Dependency Injection

Here I am using Castle Windsor as Dependency Injection container and there are many DI containers available which you can use.

On application startup we will create object of Castle Windsor and will register all components in this container.

/* Using Dependency Injection using Castle Windsor */

            WindsorContainer _windsorContainer = new WindsorContainer();

           

            // Register All types manually

            _windsorContainer.Register(Component.For<IAddress>().ImplementedBy<Address>());

            _windsorContainer.Register(Component.For<Employee>());

We can manually register all types in WindsorContainer as shown above or we can register all types in the assembly as shown below.

// Register All types in current assembly

            _windsorContainer.Register(Castle.MicroKernel.Registration.AllTypes.FromThisAssembly().Pick()

                                  .WithService.DefaultInterfaces().AllowMultipleMatches());

To create object of Employee using DI you do not need to create object of Address class. DI will automatically inject address object in Employee object.

Create Employee object as shown below

var objEmployee = _windsorContainer.Resolve<Employee>();

This is all about the concept of IOC.

You can download code here.

Do spend your time to provide comments and feedback over here or on my mail id narenkedari@gmail.com 

The Repository Pattern

Use a repository pattern to separate the logic that retrieves the data from the data source and maps it to the business entities so that business logic can acts on this model.

In short we use the repository pattern as a layer of abstraction between a datasource and business logic.

E.g. We simply call EmployeeRepository.GetAll() to get all employee details and we don’t care how we get those employee details. That’s the repository’s job. If you ever need to change the way you retrieve employee details, there’s no need to change code other than inside the repository and everything still works fine.

Use of repository pattern is to make your code in the business layer totally independent of the way you access data. It shouldn't matter to the business logic whether the underlying datastore is in SQL server, any other database or coming from a web service. In the business layer I should be purely concerned about implementing the business rules.

In other words, repository pattern is meant for separation of concerns. We want to separate out the business logic and the data access code. This makes the code easier to test and maintain.

 Let me explain this with following example.

I have a database (say Company) with two database tables named Employee and Department.

Repository Pattern implementation for this example is as follows

i.                    Create an interface for Generic Repository of type T

namespace RepositoryPattern.BaseRepository

{

    public interface IRepository<T>

    {

        IQueryable<T> GetAll();

        T GetById(int id);

        void Insert(T entity);

        void Delete(T entity);

        void Save();

    }

}

ii.                  Implementation of this interface is as follows

Client will pass the instance of DbContext in the constructor. This DbContext object is nothing but the database context on which this Repository will perform its operations.

We retrieve the entity by calling the dataContext.Set<T>() method.

The resulting DbSet of type T is the entity table we will work on in rest of the methods in the class.

Rest of the method implementation is self explanatory, implemented using the Entity Framework.

  

namespace RepositoryPattern.BaseRepository

{

    public class Repository<T> : IRepository<T> where T : class

    {

        protected DbSet<T> DbSet;

        protected DbContext databaseContext;

        public Repository(DbContext dataContext)

        {

            DbSet = dataContext.Set<T>();

            databaseContext = dataContext;

        }

        #region IRepository<T> Members

        public IQueryable<T> GetAll()

        {

            return DbSet;

        }

        public T GetById(int id)

        {

            return DbSet.Find(id);

        }

        public void Insert(T entity)

        {

            DbSet.Add(entity);

        }

        public void Delete(T entity)

        {

            DbSet.Remove(entity);

        }

        public void Save()

        {

            databaseContext.SaveChanges();

        }

        #endregion

    }

}

iii.                Repositories for Entity specific operations

Based on this Generic Repository, we will create specific repositories for entity specific operations. These specific repositories will inherit above generic repository so they will have these basic operations (GetAll, GetById, Insert, Delete, Save etc) inherited from base repository. We can write some specific operations required in these repository which can apply some business logic if required.

namespace RepositoryPattern.Repositories

{

    public interface IEmployeeRepository

    {

       

    }

    public class EmployeeRepository : Repository<Employee>, IEmployeeRepository

    {

        public EmployeeRepository(DbContext dataContext)

            : base(dataContext)

        {

        }

    }

}

iv.               Using the Repositories

To use these repositories we will create instance of the required repository by providing it a datacontext object.

In following example I am creating instance of EmployeeRepository and providing CompanyEntities object as DbContext. Here CompanyEntities is a class auto-generated by EntityFramework model (.edmx file) and it derives from DbContext class.

public static void GetAllEmployees()

        {

            CompanyEntities entities = new CompanyEntities();

            var employeeRepository = new EmployeeRepository(entities);

            List<Employee> employees= employeeRepository.GetAll().ToList();

            foreach (var emp in employees)

            {

                Console.WriteLine(" Employee {0} Details", emp.EmpNo);

                Console.WriteLine("Emp Name : {0}", emp.EmpName);

                Console.WriteLine("Emp Designation : {0}", emp.Designation);

                Console.WriteLine("Emp Department : {0}", emp.Department.DeptName);

                Console.WriteLine("------------------------------------");

            }

            Console.WriteLine("#########################");

        }

v.                    Using Generic repository for basic operations without creating specific repository

To use generic repository instead of specific repository we will create generic repository object of type required entity.

E.g. In above case instead of creating object of EmployeeRepository(), we will create object of Repository<Employee>() and rest of the code would be same.

var employeeRepository = new Repository<Employee>(entities);

That is all about Repository pattern.
You can download code here. 

Hope this gives you a enough idea about Repository Pattern to use it in your projects. :)