ASP.NET MVC: How many repositories?

Question

I am in the process is designing a website in ASP.NET MVC and am perhaps a little confused as to the exact nature of a repository.

Following the NerdDinner example, my site should have one repository which serves up the entities as I need them. However, I have also heard that you should have different repositorys that deal with specific sets of related entities....?

In the case of my site, there will be a number of entities (around 15 tables) yet the majority are all related. Is it ok / advisable to have one repository that contains all the methods that I'll need for pulling / updating / deleting etc or should I split them down?

Answer 1

I tend to use a repository per related group of entitites. i.e orderrepository might have:

Order, and OrderDetail.

and would have another for, say, Customer, CustomerProfile, etc.

This keeps the repository classes neat.

Davy

Answer 2

I create a repository for each data object.

For example, a simple library database could contain the following repositories:

• AuthorRepository
• BookRepository
• PublisherRepository

Answer 3

I think perhaps the verbiage of what is a repository might be confusing you. To me a repository is the data storage (ie; MS SQL Database) of where your data is being stored into.

Following the Repository Pattern I recommend setting up a single respository for each datastore. Most of my projects I use MS SQL so I create a Repository for that DB (I like using Subsonic for my DAL/ORM and it also implements the Repositry pattern and the ActiveRecord pattern) then I create Factories for each table. This lets me wrap up the Subsonic ActiveREcord classes and gives me abstraction.

Hope thats helpfull, perhaps...

Answer 4

If you use a generic repository which accepts types then I don't see any reason to use more than one.

we use an interface like this:

public interface IRepository
{
    void Save<ENTITY>(ENTITY entity)
        where ENTITY : Entity;

    void Delete<ENTITY>(ENTITY entity)
        where ENTITY : Entity;

    ENTITY Load<ENTITY>(int id)
        where ENTITY : Entity;

    IQueryable<ENTITY> Query<ENTITY>()
        where ENTITY : Entity;

    IList<ENTITY> GetAll<ENTITY>()
        where ENTITY : Entity;

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery)
        where ENTITY : Entity;

    ENTITY Get<ENTITY>(int id) where ENTITY : Entity;

    IList<ENTITY> GetObjectsForIds<ENTITY>(string ids) where ENTITY : Entity;

    void Flush();
}

then use in code like this:

var returnedObjects =  repository.GetAll<ObjectClass>();
var singleObject =  repository.Get<ObjectClass>(id);

Answer 5

I use a generic repository which is plenty for many entities.

For a more complex one, I simply extend this with what's needed. The best of both worlds really.

Answer 6

You should not create Repositories per each table. As queen3 said, you should create Repository per aggregate root. Like, if Products can have a Category, Category Repository should be a nested class of Products. Follow the domain logic relationship than domain objects.