Generic Repository or Specific Repository for each entity?

by

To begin with, if you are using full ORM like Entity Framework or NHibernate, you should avoid implementing additional layer of Repository and Unit Of Work.
This is because; the ORM itself exposes both Generic Repository and Unit Of Work.
In case of EF, your DbContext is Unit Of Work and DbSet is Generic Repository. In case of NHibernate, it is ISession itself.
Building new wrapper of Generic Repository over same existing one is repeat work. Why reinvent the wheel?

But, some argue that using ORM directly in calling code has following issues:

  1. It makes code little more complicated due to lack of separation of concerns.
  2. Data access code is merged in business logic. As a result, redundant complex query logic spread at multiple places; hard to manage.
  3. As many ORM objects are used in-line in calling code, it is very hard to unit test the code.
  4. As ORM only exposes Generic Repository, it causes many issues mentioned below.

Apart from all above, one other issue generally discussed is “What if we decide to change ORM in future”. This should not be key point while taking decision because:

  • You rarely change ORM, mostly NEVER – YAGNI.
  • If you change ORM, you have to do huge changes anyway. You may minimize efforts by encapsulating complete data access code (NOT just ORM) inside something. We will discuss that something below.

Considering four issues mentioned above, it may be necessary to create Repositories even though you are using full ORM – This is per case decision though.

Even in that case, Generic Repository must be avoided. It is considered an anti-pattern.

Why generic repository is anti-pattern?

  1. A repository is a part of the domain being modeled, and that domain is not generic.
    • Not every entity can be deleted.
    • Not every entity can be added
    • Not every entity has a repository.
    • Queries vary wildly; the repository API becomes as unique as the entity itself.
    • For GetById(), identifier types may be different.
    • Updating specific fields (DML) not possible.
  2. Generic query mechanism is the responsibility of an ORM.
    • Most of the ORMs expose an implementation that closely resemble with Generic Repository.
    • Repositories should be implementing the SPECIFIC queries for entities by using the generic query mechanism exposed by ORM.
  3. Working with composite keys is not possible.
  4. It leaks DAL logic in Services anyway.
    • Predicate criteria if you accept as parameter needs to be provided from Service layer. If this is ORM specific class, it leaks ORM into Services.

I suggest you read these (1, 2, 3, 4, 5) articles explaining why generic repository is an anti-pattern. This other answer discusses about Repository Pattern in general.

So, I will suggest:

  • Do NOT use repository at all, directly use ORM in your calling code.
  • If you have to use repository, then do not try to implement everything with Generic Repository.
    Instead, optionally create very simple and small Generic Repository as abstract base class. OR you can use Generic Repository exposed by your ORM as base repository if ORM allows it.
    Implement Concrete Repositories as per your need and derive all them from Generic Repository. Expose concrete repositories to calling code.
    This way you get all the good of generic repository still bypassing its drawbacks.
    Even though very rare, this also helps switching ORM in future as ORM code is cleanly abstracted in DAL/Repositories. Please understand that switching ORM is not a primary objective of Data Access Layer or Repository.

In any case, do not expose Generic Repository to calling code.

Also, do not return IQueryable from concrete repositories. This violates basic purpose of existence of Repositories – To abstract data access. With exposing IQueryable outside the repository, many data access decisions leak into calling code and Repository lose the control over it.

do I need to create a repository for each entity or implement a generic repository for the context

As suggested above, creating repository for each entity is better approach. Note that, Repository should ideally return Domain Model instead of Entity. But this is different topic for discussion.

does a generic repository works for EF Database First?

As suggested above, EF itself exposes Generic Repository. Building one more layer on it is useless. Your image is saying the same thing.

More Related Contents:

  1. Method cannot be translated into a store expression
  2. EF Including Other Entities (Generic Repository pattern)
  3. An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key
  4. Using Simple Injector with Unit Of Work & Repository Pattern in Windows Form
  5. Entity Framework – how do I get the columns?
  6. Where to convert business model to view model?
  7. How to write this EF Mock setup code as a reusable Generic Boilerplate?
  8. .NET Managing Layers Relationships
  9. How do I clone a generic list in C#?
  10. Remove duplicates from a List in C#
  11. How to dynamically create generic C# object using reflection? [duplicate]
  12. Is there a generic constructor with parameter constraint in C#?
  13. Unable to update the EntitySet – because it has a DefiningQuery and no element exist
  14. How do I stop Entity Framework from trying to save/insert child objects?
  15. Entity Framework – Code First – Can’t Store List
  16. Making a generic property
  17. foreach vs someList.ForEach(){}
  18. Pass connection string to code-first DbContext
  19. No type inference with generic extension method
  20. A specified Include path is not valid. The EntityType does not declare a navigation property with the name *
  21. Specifying generic collection type param at runtime [duplicate]
  22. How to group by on 2 child entities and get total of both this child entities?
  23. How to tell Fluent NHibernate not to map a class property
  24. update-database: “A network-related or instance-specific error occurred while establishing a connection to SQL Server”
  25. Better way to query a page of data and get total count in entity framework 4.1?
  26. Calling a SQL User-defined function in a LINQ query
  27. The given key was not present in the dictionary. Which key?
  28. Cannot find command ‘dotnet ef’
  29. The ObjectContext instance has been disposed and can no longer be used for operations that require a connection [duplicate]
  30. C# List: why you cannot do `List foo = new List();`

Leave a Comment