Looking into the Generic Repository Pattern, Entity Framework and ASP.Net MVC

When developing/architecting our custom ASP.Net MVC applications we do use the Repository Pattern/Generic Repository Pattern.

I want to share my experience and thoughts with the community of developers out there that use Generic Repositories in their code.

At first a definition is appropriate. Martin Fowler gives the definition of the Repository Pattern: "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.". You can read more link in his post.

In simpler words, the Repository Pattern creates an abstraction layer between the data access layer and the business logic layer of an application.

Repository design pattern is a way to simplify data access and enforce separation of concerns.

When I began learning about repositories and implementing them in my own software design, it had a huge impact on my application architecture.

It helped me to automate testing practices, forced me to consider separation of concerns with each method and behavior I added to my code. In a nutshell the pattern makes one to write good, clean, testable, low coupling, non-duplicate code

Generic Repositories are implemented by using Type parameters and interfaces, which allows the Repository to remain agnostic to specific classes as long as the type passed in adheres to the contract of the interface.  If the interface contains all the methods and properties we’ll need inside our repository, we can operate on any class that implements it.

There are many ways to implement the repository pattern and I will show some bad ways to use and finally I will talk about its right usage.

This is the first approach to implement the Generic Repository Pattern. I am just creating a new empty project and I am adding a class library project in it.

Let's say that I will implement the Generic Repository Pattern for two domain objects (Product and Customer) that need data access operations because these in memory domain objects at one point through Entity Framework will have to materialize into rows of data in the data store.

1) This is the code below for the Customer Repository(ICustomerRepository)

public interface ICustomerRepository {


IQueryable<Customer> GetAll();

Customer GetByID(int CustomerId);

IQueryable<Customer> FindBy(Expression<Func<Customer, bool>> predicate);

void Add(Customer entity);

void Remove(Customer entity);

void Edit(Customer entity);

void Save();

}

 

2) This is the code below for the Product Repository (IProductRepository)

public interface IProductRepository
{

IQueryable<Product> GetAll();


Product GetByID(int ProductId);

IQueryable<Product> FindBy(Expression<Func<Product, bool>> predicate);

void Add(Product entity);

void Remove(Product entity);

void Edit(Product entity);

void Save();

}

As you can understand I am already repeating almost identical code because the two repositories for the two domain objects have identical data access methods.

3) I am going to implement now the Customer Repository.

This is the code below.

public class CustomerRepository:ICustomerRepository
{

private readonly CustomerEntities context = new CustomerEntities();

public IQueryable<Customer> GetAll()
{

IQueryable<Customer> query = context.Customers;
return query;
}

public Customer GetByID(int CustomerId)
{

var query = this.GetAll().FirstOrDefault(x => x.CustomerId == CustomerId);
return query;
}

public void Add(Customer entity)
{

context.Customers.Add(entity);
}

public void Remove(Customer entity)
{

context.Customers.Remove(entity);
}

public void Edit(Customer entity)
{

context.Entry<Customer>(entity).State = System.Data.EntityState.Modified;
}

public void Save()
{

context.SaveChanges();
}

4) The next step would be to implement the Product Repository for the Product domain object. As you can understand the code would be almost identical. I have already violated the DRY (Do Not Repeat Yourself) principle.

The code above implements the Repository pattern but needs reengineering because we had to do the above implementation for all our classes in our domain.

5) The first step towards re-engineering the code is to create a generic interface. This is the new generic interface.

 public interface IGenericRepository<T> :IDisposable where T : class
{

IQueryable<T> GetAll();


IQueryable<T> FindBy(Expression<Func<T, bool>> predicate);

void Add(T entity);

void Remove(T entity);

void Edit(T entity);

void Save();
}

6) Νow we need to re-engineer our code for the two interfaces IProductRepository and ICustomerRepository

public interface IProductRepository : IGenericRepository<Product>
{

Product GetByID(int ProductId);


}

public interface ICustomerRepository:IGenericRepository<Customer>
{

Customer GetByID(int CustomerId);

}

I only need to implement GetByID method and the other methods come with IGenericRepositoy<T> interface.

If I move to the next step and implement the concrete classes (CustomerRepository,ProductRepository), I need to create all the methods in them. So we still duplicate and repeat the code.

7) We must re-engineer the code and come up with a better solution. I will create an abstract class that will inherit from my generic interface.The code follows.

public abstract class GenericRepository<C,DBC> :
IGenericRepository<T> where T : class where DBC : DbContext, new()
{

private DBC _newentities = new DBC();


protected DBC Context
{

get { return _newentities; }
set { _newentities = value; }
}

public virtual IQueryable<T> GetAll()
{

IQueryable<T> query = _newentities.Set<T>();
return query;
}

public IQueryable<T> FindBy(System.Linq.Expressions.Expression<Func<T, bool>> predicate)
{

IQueryable<T> query = _newentities.Set<T>().Where(predicate);
return query;
}

public virtual void Add(T entity)
{
_newentities.Set<T>().Add(entity);
}

public virtual void Remove(T entity)
{
_newentities.Set<T>().Remove(entity);
}

public virtual void Edit(T entity)
{
_newentities.Entry(entity).State = System.Data.EntityState.Modified;
}

public virtual void Save()
{
_newentities.SaveChanges();
}

private bool disposed = false;

protected virtual void Dispose(bool disposing)
{

if (!this.disposed)
if (disposing)
_newentities.Dispose();

this.disposed = true;
}
public void Dispose()
{

Dispose(true);

}

}

I created an abstract class which implements IGenericReposity<T> interface but also accepts another type parameter a type of DbContext class. 

The methods above which implement basic data access methods are marked as virtual so they can be overwritten.

8) The concrete implementation for the two domain classes follow

public class ProductReposiltory :
GenericRepository<DBEntities, Product>, IProductRepository
{

public Product GetByID(int ProductId)
{

var query = this.GetAll().FirstOrDefault(x => x.ProductId == ProductId);
return query;
}
}

public class CustomerRepository:GenericRepository<DBEntities, Customer>,ICustomerRepository
{

public Customer GetByID(int CustomerId)
{

var query = this.GetAll().FirstOrDefault(x => x.CustomerId == CustomerId);
return query;
}



}

My concrete classes inherit from the Generic Repository and their own specific interface which in their turn inherit from the the IGeneric Repository.

Through a Generic Repository we can use one class to manage all of the database operations for our domain entities.  

We don’t have to rewrite the create, read, update and delete operations for each of our entities.

Another great benefit of the pattern is that we could swap out our data access layer and as long as it adheres to the Repository contracts, it would still work.

I managed to have a code that implements separation of concerns by having a separate layer that creates that abstraction. My code is more testable and I do not have to repeat it.

Finally, I would like to point out that Generic Repositories work well with Dependency Injection. This means in our MVC controller or other classes that implement the business logic,our BLL, we can ask for a repository of any type, and our DI Container should be able to provide that for us.  I won't talk about Dependency Injection in this post but I will write a post on DI soon.

Ι will create in another post the MVC project that will use my repositories.

Hope that helps!!!

1 Comment

  • Thank you for the article! - Could you possibly throw up a link for the project files?? - You have written some nice things about extending a generic repository (Been looking for it for a while! Thank you! :) )

Comments have been disabled for this content.