Easy implementation of Repository Pattern

Question

I am using ADO.NET directly with MVC 5 and not Entity Framework.

I am referring to this example to implement Repository Pattern.

For a simple implementation of Repository Pattern:

1. I will create a Model
2. I will create an interface with CRUD method declarations
3. I will create a class in Data Access Layer which will implement the above interface and will have CRUD method implementations

I want to know why Interface is used? Can I not directly use a class, as per point (3) above.

What is the role of interface?

As per the above three points mentioned, is it the correct implementation of Repository Pattern?

Answer 1

In good-designed code you have to use interfaces, but not implementations. It have benefits. Imagine you have a class with a code fragment:

IBookRepository bookRepository;

public Book GetInterestingBook() {
  var book = bookRepository.getBooks().FirstOrDefault(x => x.IsInteresting);
  return book;
}

Now I'll show you some benefits:

1. Using interface allows you to create bookRepository instances implicitly via Dependency Injection (Ninject, Unity, etc. There are many of them). If you decide to change repository implementation from Entity Framework to NHibernate you don't need to make changes in code. Just change mapping in mapping file to use for IBookRepository NHibernateRepository instead of EFBookRepository. Of course, NHibernateRepository should be developed too.

2. Using interface allows you to implement great unit-testing via MockObjects. You just need to implement MockBookRepository and use it on injection. There are many Mock frameworks that can help you with it - Moq for example.

3. You can switch repositories dynamically without changing you code. For example if your database is temporary down, but you have another one that can handle new orders for example as they are critical (bad example, i know). In this case you detect DB fall down and make something like:

   currentRepository = temporaryOrdersOnlyRepository;

Now your code continues functioning except your get data and delete methods returns exceptions but CreateNewOrder() method will save orders to string file )

Good luck!

Answer 2

Here is a service

public interface IFoodEstablishmentService
{
    Task<int> AddAsync(FoodEstablishment oFoodEstablishment);
    Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment);
}

This is my normal implementation

public class FoodEstablishmentService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       // Insert Operation
        return result;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        // Update Logic
        return result;
    }
}

This is how i use it

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentService();
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

But wait what if I might need to pass my insert logic through queue rather than directly to server, wait for insert operation to complete and then return result, rather pass on queue and then the queue worker handles those operation? So instead of messing everything, I just implement another class with same interface

public class FoodEstablishmentQueueService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       // Insert Queue Operation
        return result;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        // Update Queue Logic
        return result;
    }
}

And this is how I use it, isn't it easy without breaking anything, and with DI Container as stated on earlier answer even works better

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentQueueService();
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

I guess don't choose for best pattern rather start with any and then slowly you will have need for something more and then pattern comes to play in addition Repository pattern or generic repository pattern might not be ideal pattern for large scale application where select logic is beyond selecting just a model data. Please search for CQRS pattern.

Answer 3

That tutorial is pretty useless. It's just a wrapper over EF's DbSet. Very bad example. The repository pattern itself means you need to design a proper interface based on the domain needs . Usually you have at least 3 needs: Add, Get, Save. But everything depends on your domain and that's important: there is no recipe, it's just what the app needs.

The repository implementation is just the persisting/loading of whole business objects (where a business object is a business concept). You've chosen Ado.net ( you should have chosen a micro-Orm, as there is no benefit in using ado.net) to communicate with the db. OK, just do the saving to db, querying the db routine.

There is no recipe/rule of how to implement a repository. The 'hard' part is designing the interface. The implementation is just a class using the db (in whatever way you want).

We're using interfaces because, usually, a repo's interface is part of the domain, while its implementation is part of the persistence. This also allows for multiple repository implementations and for easy testing (via mocking).

Btw, you have to understand that the repository pattern is just a simple principle. It can be implemented in what way you want, there is no a 'correct' way. What needs to be 'correct' though is the interface design in the way that only business objects should be used and no implementation details (like IQueryable) should be leaked.