Dependency Injection in C# .NET

Dependency injection basically allows us to create loosely coupled, reusable, and testable objects in your software designs by removing dependencies.

We will take a look into the Object dependencies before digging in more.
Consider a scenario of fetching an employee details and show display in UI. Let us say create a Business logic layer class named EmployeeBAL and a data access layer class named EmployeeDAO

public class EmployeeDao
{
//Some code
}
public class EmployeeBAL
{
var employeeDAO = new EmployeeDao();
//Some code
}

From the above code you will notice one thing that we are creating EmployeeDAO instance inside the Business logic layer class. So here comes the dependency

What is wrong if we have a dependency?

Think about whether your code is unit testable. We cannot fully unit test the EmployeeBAL as it has a dependency on Employee DAO. So we can say as long as the composition of the DAO exists within the BAL we cannot unit test the EmployeeBAL.

You will also notice one more thing here; with this type of implementation you will see a high coupling of BAL and DAL.

How to make it loose coupling?

The basic idea behind Dependency Injection is that you should isolate the implementation of an object from the construction of objects on which it depends.

Coming to the example, we should be isolating the implementation of EmployeeBAL object and the construction of the dependent EmployeeDAO object.

We will see how we can make loosely coupled objects in detail

Constructor based dependency injection
We will have to modify the EmployeeBAL to accept an EmployeeDAO instance within its constructor.

public class EmployeeDao
{
//Some code
}

public class EmployeeBAL
{
EmployeeDao employeeDAO;
public EmployeeBAL(EmployeeDAO employeeDao){
this.employeeDAO = employeeDao;
}
//Some code
}

Property based dependency injection

With property based injection we will have a public getter and setter Property of type EmployeeDao so that the dependency can be externally set.
public class EmployeeBAL
{
Public EmployeeDao EmployeeDataAccess{ get; set; }
}
var employeeBAL = new EmployeeBAL();
EmployeeBAL.EmployeeDataAccess = new EmployeeDao();

Wait!!!

The above ones are just some techniques of injecting the dependency. We are still yet to discuss one more interesting thing Unit Testing.

Are you agreeing that we have removed the DAO creation from the Business Logic EmployeeBAL? Yes it is good but it still depends on the actual instance of EmployeeDao.

Consider the below mentioned implementation of the same sample senarios

interface IDataAccess
{
//Some code
}

class EmployeeDao : IDataAccess
{
//Some code
}

public class EmployeeBAL
{
private IDataAccess dataAccess;
public BusinessFacade(IDataAccess dao)
{
  dataAccess = dao;
}
}

You can notice we are doing a constructor dependency injection but most important thing here
is we are using Interface type than creating a strongly typed object.

The advantage that we are getting here is we can have an in memory data access object of
IDataAccess interface type and we can easily inject the dependency to the EmployeeBAL.

By this way we no need to have the actual database dependency.

Are you happy that we can unit test the BAL without the data access dependency?

Advantages of Dependency Injection

The primary advantages of dependency injection are:
Loose coupling
Centralized configuration
Easily testable

Another Post about DI: Understand Constructor Injection in Dependency Injection.

I found 1 more Link Usable-
Design pattern Inversion of control and Dependency