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?

Oldest

Answer 1

I create a repository for each data object.

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

• AuthorRepository
• BookRepository
• PublisherRepository

Olivette

so in this case which repository would return all the books by a specific author? – Oldest

The bookrepository, since you are requesting books – Olivette

I see. Maybe im thinkin about this the wrong way but it seems weird....in terms of entities (entity framework in my case) i cant help but thinkin that if I have the author then I have the books (author.books for example). So in that respect is seems weird to split them into different repositorys. – Oldest

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.

Cherida

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

).

Checkrein

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);

Legator

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

Syce

I'm curious about the statement of creating a repository for each data store. What if I have a many-to-many "entity" that does nothing more than just store 2 IDs (as it's primary key)? Do I need to create a repository out of that, or can I just include some of the basic fetch/save methods in another, related repository? I thought repositories should focus more on the aggregate entities. – Kirshbaum

Thanks for all the replies guys - very helpful. This 'generic' route has me interested although being the beginner that I am Im not sure how I would go about setting it up. Im using the entity framework as my ORM.... – Oldest

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.

Dobsonfly

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.

Eadie

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

Krasnoff