Question

I have implemented Repository Pattern and Unit of Work into my ASP.NET Web API project.

It's working great. Now one question came to me about a Repository that can handle all about Setup Catalogs in my application.

Right now I have to create into my Unit of Work all public repositories that make a reference to an EF entity like below:

public IRepository<Document> Document { get { return GetStandardRepo<Document>(); } }

Where Document is an EF Entity. IRepository implements the following methods:

public interface IRepository<T> where T : class
    {
        IQueryable<T> GetAll();
        IQueryable<T> GetAllReadOnly();
        T GetById(int id);
        void Add(T entity);
        void Update(T entity);
        void Delete(T entity);
        void Delete(int id);
    }

I have about 20 tables for Setup Catalogs in my database so If I follow this pattern I will have to create 20:

public IRepository<SetupEmployeeType> Document { get { return GetStandardRepo<SetupEmployeeType>(); } }
public IRepository<SetupMaritalStatus> Document { get { return GetStandardRepo<SetupMaritalStatus>(); } }
public IRepository<SetupRelationshipCode> Document { get { return GetStandardRepo<SetupRelationshipCode>(); } }
public IRepository<SetupLocationType> Document { get { return GetStandardRepo<SetupLocationType>(); } }
.....
.....

One solution I was thinking is to create my own custom IRepository implementation maybe ICatalogRepository like below:

 public class CatalogRepository : EFRepository<EF Entity>, ICatalogRepository
        {
            public CatalogRepository (DbContext context) : base(context) { }


            public IEnumerable<SetupEmployeeType> GetEmployeeTypes()
            {
                var catalog = DbContext
                    .Set<SetupEmployeeType>()
                    .ToList();

                return catalog;

            }

public IEnumerable<SetupMaritalStatus> GetMaritalStatus()
            {
                var catalog = DbContext
                    .Set<SetupMaritalStatus>()
                    .ToList();

                return catalog;

            }
        }

My question is that CatalogRepository has to inherits from EFRepository but T is not just one entity because I will return diferent entities from diferent methods.

Is that the correct way to do this?

Was it helpful?

Solution

Yeah, don't use this anti pattern (generic repository wrapping DbContext while exposing EF entities). If you really want to use the Repository make the repository interface return ONLY business (or view models if it's a query repo) objects, never IQueryable or other details exposing EF or whatever are you using.

Simply put create a repository for your NEEDS, forget about generic stuff it's an anti pattern. So your CatalogRepository will use a DbContext to issue all the queries needed, then assemble a view model/business object from the results and returns that.

The app will know only about the Repo, never about EF. The queries will remain at the DAL level (not in your app/service/controller) and your app is decoupled, Separation of Concerns is respected.

A class wrapping DbContext is at best useless (what value does it bring?) and at worst a leaky abstraction. Make your life easier, if you want to work directly with EF entities and EF, work directly with EF. If you want to decouple the rest of the app from persistence details (note I've said persistence, not rdbms) use Repository properly. But don't kid yourself you're using the Repository pattern just because you have a class named repository. You should know exactly why are you using a pattern and what benefits it brings to your situation. It's not best practice if you don't understand why.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top