Repository Pattern Standardization of methods

All I am trying to find out the correct definition of the repository pattern.

My original understanding was this (extremely dumbed down)

Separate your Business Objects from your Data Objects
Standardize access methods in data access layer.

I have really seen 2 different implementation, and there are no formal examples online, the ones i have seen are tucked away in books.

Implementation 1 :

public Interface IRepository<T>{
      List<T> GetAll();
      void Create(T p);
      void Update(T p);
}


public interface IProductRepository: IRepository<Product> {
      //Extension methods if needed
       List<Product> GetProductsByCustomerID();
}

Implementation 2 :

public interface IProductRepository {
      List<Product> GetAllProducts();
      void CreateProduct(Product p);
      void UpdateProduct(Product p);
      List<Product> GetProductsByCustomerID();
}

Notice the first is generic Get/Update/GetAll, etc, the second is more of what I would define "DAO" like.

Both share an extraction from your data entities. Which I like, but i can do the same with a simple DAO. However the second piece standardize access operations I see value in, if you implement this enterprise wide people would easily know the set of access methods for your repository.

Am I wrong to assume that the standardization of access to data is an integral piece of this pattern ? If both are correct why would one choose to do implementation 2?

Rhino has a good article on implementation 1, and of course MS has a vague definition and an example of implementation 2 is

c# design-patterns repository-pattern

Edit Report

2 Answers

I am a great fan of the generic repository pattern but I think you should strongly consider not directly inheriting from the interface as it can become a very large limitation especially since many times the code for the generic interface will be the same that it could be defined in an abstract base class that you will no longer be able to have more than 1 generic repository inside a class.

I recommend having your IProductRepository implementer access the generic IRepository<Product> through delegation and inject that in through the constructor so you can compose your class of possibly many IRepositories and group them behind a single interface in a way that makes sense.

I wrote a blog on this topic while it specifically references NHibernate this pattern can be applied to any type of repository: Creating a common generic and extensible NHiberate Repository version 2

answered 2010-04-21T17:23:54.727

With the introduction of LINQ in .NET, a generic repository pattern becomes much easier to realize:

public interface IRepository<T> : IQueryable<T>
{
    void Add(T item);
    void Remove(T item);
}

To qualify as a repository, it merely needs to be able to access data in the underlying store (easily provided by IQueryable) and modify the contained data.

You can provide extensions to the base interface to provide hooks for more entity-specific behaviour (such as wiring into a stored procedure call for a SQL-based repository), but the majority of operations can be completed by the simple interface.

answered 2010-04-27T12:13:53.463

Repository Pattern Standardization of methods

2 Answers

Your Answer