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

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 2

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

).