One big repository vs. many little ones?

Question

I have several product tables in my database:

ProductTypes
ProductCategories
ProductCategoryItems
ProductInventory

The way I see it now, I can make IProduct which would have methods such as:

FindAllTypes()
FindAllCategories(int typeId)
FindAllItems(int categoryId)

Or, I can separate each to mimic the table structure: IProductType, IProductCategory, etc.

Is there a reason to go with one over another?

score 13 · Accepted Answer · answered Jun 09 '11 at 21:48

13

The idea of repositories is to delegate each one with responsibility for a single entity. In this case making a repository for each entity is recommended. You can go for the big repository one as well, but is not the best solution. In the end you'll get a HUGE class with lots of methods and really tight coupled. Also difficult to give maintenance to.

answered Jun 09 '11 at 21:48

Luis Aguilar

4,331
6
36
55

2

You will see repository per class identified as an anti-pattern in many circles. It's advised by Eric Evans in his book Domain Driven Design to create a repository per Aggregate root. Please search these terms as I'm currently in a rush and cannot create a link. – Chazt3n Oct 08 '15 at 13:36

score 6 · Answer 2 · answered Jun 09 '11 at 21:55

6

I don't think having a huge repository is really a good idea, then you'd basically have a data access god class that does everything.

I like to have a base Repository<T> which does common operations such as GetById and GetAll. I normally have all my repositories inherit this base class to get the common methods for free, so I don't have to keep rewriting the same code.

answered Jun 09 '11 at 21:55

Rex Morgan

2,979
2
21
32

2

+1 for the base `Repository`. I've seen so many repository implementations repeat these common methods without using a base class! Argh! – TheCloudlessSky Jun 10 '11 at 00:38
1

I second that. `GenericRepository` ftw! +1 – RPM1984 Jun 10 '11 at 01:25

score 4 · Answer 3 · answered Jun 09 '11 at 22:39

In my opinion it very much depends on the business domain model, it's very important to determine what are your main business entities. Not necessarily every table in the DB is directly mapped to a business entity. Tables are just representations of your one or many entities in a normalized way for relational databases.

Try to picture your domain model beyond the restrictions of normalized relational databases, is there really more than one business concept? Repositories should be constructed around solid, whole, first-class business entities.

My advice would be to have an IProductRepository with the necessary methods to implement CRUD operations and grow it as needed. You don't want to get too ambitious interfaces beacuse you may not need most of it, and it could be a burden. The important thing about interfaces is to decouple your code from the persistence schema, so you can latter offer the flexibility to switch between them.

Maybe in the future the business will need to evolve to a more detailed representation of -for instance- the product's providers, and in that moment you'll use your good judgement to decide wether that represents an important business entity worthy of a dedicated repository or not.

Hope this helps.

Absolutely, there are some entities that can only exist as children of others, those are perfect candidates to be under the same repository — BlackTigerX, Jun 10 '11 at 03:04

score 3 · Answer 4 · edited May 23 '17 at 11:48

I disagree with the others (edit: except with Isaac). The small repositories are a facade (not the pattern).

If the entity types are coupled (have navigation properties to each other) then they are not really separatable.

Modifying one entity type and committing the changes may commit change to others.

Also, you can not create any small repository above the same unit of work, since the ORM only has a limited amount of entities mapped to the database.

Divide your model into separatable domains and create one specific unit of work for each domain.

On these unit of works create aggregate roots for each entity type that you may require immediate access to.

Each root should have specifically typed add, remove, getbykeys, query and etc methods.

The unit of work should have the commitchanges and alike methods on it.

Each of the roots is similar to the small repositories the others mentioned, however, the unit of work is the real medium sized repository (of which your model may have more than one type of).

Example:

// Create one of these
interface IUnitOfWork
{
    void Commit();
}

// Create one of these
interface IEntitySet<TEntity> where TEntity : class
{
    void Add(TEntity entity);
    void Remove(TEntity entity);
    TEntity Create<TSpecificEntity>() where TSpecificEntity : TEntity;

    IQueryable<TEntity> Query();
}

// Create one of these per entity type
interace IEntitySetOfTEntity1 : IEntitySet<Entity1>
{
    TEntity1 GetByKeys(int key1);
}

interace IEntitySetOfTEntity2 : IEntitySet<Entity2>
{
    TEntity1 GetByKeys(short key1, short key2);
}

// Create one of these per separatable domain
interface IDomain1UnitOfWork : IUnitOfWork
{
    IEntitySetOfTEntity1 Entity1s
    {
        get;
    }

    IEntitySetOfTEntity2 Entity2s
    {
        get;
    }
}

All these interfaces and their implementations can be auto-generated.

These interfaces and their implementations are very light weight and by no means are any of them "a HUGE class with lots of methods". Since they can be auto-generated, maintenance is easy.

Specific functionalities can be added to the interfaces IDomain1UnitOfWork, IEntitySetOfTEntity1 and alike by using:
a. extension methods
b. partial interfaces and classes (less recommended, since this results in a less clean DAL)

The IEntitySetOfTEntity1 like interfaces can be disgarded if you use extension methods to add the GetByKeys() methods to IEntitySet<Entity1>.

One big repository vs. many little ones?

4 Answers4