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 create a repository for each data object.

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

• AuthorRepository
• BookRepository
• PublisherRepository

Answer 2

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 3

In domain driven design, there's a rule that repositories are per aggregate root. You can read more about it here.

The more I read, the more I think that NerdDinner is too often seen as a collection of good practices, while it's absolutely not (see here for a discussion of, particularly, NerdDinner repository). That's why people often blame other MS examples like Oxite (and here:

Developers will flock to it, praise it, and blindly accept it as gospel because it comes from Microsoft (it's already well on its way). Sadly, any developer which adopts its spirit will be left with an unmaintainble, untestable and unreadable mess

).

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 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 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.

Answer 7

Queen3 is right, you can follow that Aggregate Root theory. I basically group my repository not thinking in Entities but how they group logically in the application I'm building.

For example:

CustomersRepository
OrdersRepository
...

In CustomerRepository I would put methods for GetCustomers, GetCustomer, AddCustomer, DeleteCustomer, AddCustomerContact, DeleteCustomerContact.

In OrdersRepository I would put methods for GetOrders, GetOrder, AddOrder, CancelOrder, CloneOrder, AddOrderDetail, DeleteOrderDetail and so on.

Answer 8

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