Repository pattern - Why exactly do we need Interfaces?

Question

I have read from internet I got this points which says Interfaces is used for this

• Use TDD methods
• Replace persistance engine

But I\'m not

Answer 1

You would expose your repository as an interface:

public interface IEmployeeRepository
{
    List<Employee> GetAll();
}

This would allow you to have many different implementations of the interface, such as the default one:

public class EmployeeRepository : IEmployeeRepository
{
    public List<Employee> GetAll()
    {
        // Return from db.
    }
}

Or a test one:

public class TestEmployeeRepository : IEmployeeRepository
{
    public List<Employee> GetAll()
    {
        // Stub some dummy data.
    }
}

Your code consuming the repository is then only interested in using the interface:

IEmployeeRepository myRepo = MyRepositoryFactory.Get<IEmployeeRepository>();

The secret sauce is the factory, or another mechanism by which to resolve the interface into a usable type (a Dependency Injection framework such as Ninject, or Castle Windsor will fulfil this role).

The point is, the consuming code doesn't care about the implementation, only the contract (the interface). This allows you to swap out implementations for testing purposes very easily and promotes loose coupling.

Just to clarify, there is no link between the use of interfaces and the repository pattern specifically, it is just another pattern that can make use of them.

Answer 2

So how interfaces come into picture ?

Like this:

public interface IEmployeeRepository
{
    Employee[] GetAll();
}

and then you could have as many implementations as you like:

public class EmployeeRepositoryEF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying your EF DbContext
    }
}

public class EmployeeRepositoryXML: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying an XML file
    }
}

public class EmployeeRepositoryWCF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying some remote WCF service
    }
}

and so on ... you could have as many implementation as you like

As you can see it's not really important how we implement the repository. What's important is that all repositories and implementations respect the defined contract (interface) and all posses a GetAll method returning a list of employees.

And then you will have a controller which uses this interface.

public class EmployeesController: Controller
{
    private readonly IEmployeeRepository _repository;
    public EmployeesController(IEmployeeRepository repository)
    {
        _repository = repository;
    }

    public ActionResult Index()
    {
        var employees = _repository.GetAll();
        return View(employees);
    }   
}

See how the controller no longer depends on a specific implementation of the repository? All it needs to know is that this implementation respects the contract. Now all that you need to do is to configure your favorite dependency injection framework to use the implementation you wish.

Here's an example of how this is done with Ninject:

1. Install the Ninject.MVC3 NuGet

2. In the generated ~/App_Start/NinjectWebCommon.cs code you simply decide to use the EF implementation with a single line of code:

   private static void RegisterServices(IKernel kernel)
   {
       kernel.Bind<IEmployeeRepository>().To<EmployeeRepositoryEF>();
   }        
   

This way you no longer need to do any manual instantiations of those repository classes and worry about upcasting or whatever. It is the dependency injection framework that manages them for you and will take care of injecting the defined implementation into the controller constructor.

And by simply modifying this configuration you could switch your data access technology without touching a single line of code in your controller. That's way unit testing in isolation also comes into play. Since your controller code is now weakly coupled to the repository (thanks to the interface we introduced) all you need to do in the unit test is to provide some mock implementation on the repository which allows you to define its behavior. This gives you the possibility to unit test the Index controller action without any dependency on a database or whatever. Complete isolation.

I also invite you to checkout the following articles about TDD and DI in ASP.NET MVC.