Question

I am slowly trying to improve my knowledge of Enterprise Application Development. With regard to best practices I have learned about creating concrete repository implementations of iRepository interfaces and so far it makes sense.

Where I am challenged is when (as it often happens) I want to return data that is coming from two or more tables in one result set, and how to best approach this.

I understand that identifying aggregate roots is probably the best way to go but am wondering how to approach this with regard to interfaces and repositories when it comes to using specific/custom repositories vs generic repositories.

Generic Repositories seem like a great way to cut down on the need to create individual iRepositories for each required implementation, but the problem is that not all of my concrete classes have a need for all of the methods in the Generic Repository Interface, ie sometimes I will need more and other times I will need less.

I am wondering what is the best practice to approach this situation? Do developers normally have one generic repository interface and then create more specific ones for more specific Data Access needs?

I have used this project as a guideline for best practice:
http://efmvc.codeplex.com/

Answer 1

The generic repository should only contain the minimal amount of methods. I usually then create a specific repository for each aggregate root (a new interface and a new class which inherits the generic repository).

Something like:

public interface IRepository<T>
{
    void Create(T);
    void Update(T);
    T Get(int key);
}

public interface IUserRepository : IRepository<User>
{
    User GetByUserName(string userName);
}

So the user repository looks like:

public class UserRepository : Repository<User>, IUserRepository
{
     public User GetByUserName(string userName)
     {
         return DbContext.Users.FirstOrDefault(x => x.UserName == userName);
     }
}

But lately I’ve moving towards queries instead, like I describe here: http://blog.gauffin.org/2012/10/griffin-decoupled-the-queries/