Repository implemented in EF Core: use whole DbContext or only DbSet? [closed]

The typical approach is to inject the DbContext rather than DbSets as it is a simpler matter to configure your DI container to provide the DbContext than each DbSet from a scoped DbContext instance.

Regarding the comment "The extra layer is for the easier maintenance of the code in case I would like to change from EF Core to some other implementations." I strongly recommend not adopting a repository for this reason. The justification for this stance is that by attempting to abstract away EF, you severely limit the capabilities and performance that EF can provide for your application, or you introduce a considerable amount of complexity and overheads to try and maintain some of those capabilities.

Take a classic example:

public IEnumerable<Customer> GetAllCustomers() { return _context.Customers.ToList(); } 

A method like this would load all customers from the DB into memory. What happens if you want to filter the records, or sort, or paginate results? what happens if you just want a count? What about situations where you just need the IDs and a couple of columns?

Even a simpler example:

public Customer GetCustomerById(int customerId) { return _context.Customers.Single(x => x.CustomerId == customerId); } 

This seems safe enough, but what about related data? If a customer has addresses, orders, etc. that I will want to retrieve, we are either relying on lazy loading or kicking off additional queries, how can it know whether it would save time by eager loading related data, and what related data? (vs. eager loading everything)

Pretty soon the code starts including parameters and expressions and such to try and facilitate eager loading, pagination, sorting, etc.. Methods get added to do things like get a count, or project the results to specific DTOs/ViewModels rather than returning entities, otherwise using methods like the above will result in significant performance issues. It becomes a self-fulfilling prophecy. "I abstract away EF in case I need to replace it in the future... I need to replace EF because it's too slow."

The best reasons for using a repository pattern that I can offer boil down to two things:

1. Making it easier to unit test. (Repositories are generally easier to mock than DbContext/DbSets)

2. Centralize core filtering rules. For example in soft-delete systems, centralizing IsActive flag filtering. This can also centralize things like authorization checks.

A third reason I personally use is that the repository serves as a good Factory class for validating inputs and returning a "complete enough" entity. For instance there are often required fields and relationships needed before an entity can be saved, along with optional fields. The factory method in the repository ensures all required details are provided and has access to the DbContext to validate/load related references.

The repository pattern I use employs IQueryable to provide the basic abstraction for unit testing while keeping the repositories themselves very simple, lightweight, and flexible.

public IQueryable<Customer> GetAllCustomers() { return _context.Customers.AsQueryable(); } public IQueryable<Customer> GetCustomerById(int customerId) { return _context.Customers.Where(x => x.CustomerId == customerId); } 

Even for the implied singular select (ById) I return IQueryable as this still accommodates projection via Select or ProjectTo, as well as eager loading scenarios my consumer will know it needs, or simply doing a .Any() if all I want is to check if an item exists.

For instance, my consuming code in one place can use:

var customer = Repository.GetCustomerById(customerId) .Include(x => x.Orders) // .... .Single(); 

... where that code might look to update some data about the customer and it's relative orders.

while another consuming statement might use:

var customer = Repository.GetCustomerById(customerId) .ProjectTo<CustomerSummaryViewModel>(config) .Single(); 

... where this code is only interested in projecting a summary view model of the customer and related data.

If we want to tie in IsActive checks, or ensure that data returned looks at the currently logged in user and any data restrictions etc. the repository is a good place to tie those very universal filters in. If you're not planning on incorporating unit tests, or these types of uniform checks, then a repository doesn't really give you any benefit.

Note that this abstraction does not hide the fact that we are relying on Entity Framework, nor should it attempt to. Trying to hide EF would mean either that we give up a large portion of the power and flexibility that EF can provide us to work with the domain, or we need to explore highly complex code to try and accommodate things that it can provide out of the box. Even clever solutions like passing Expressions as parameters to try and handle sorting, eager loading, or projection to avoid exposing/polluting code with EF-specific or domain specific rules/knowledge are ultimately flawed because they must still conform to EF-specific rules. For instance, those expressions fed to EF must not include method calls or reference unmapped properties etc. They must be aware of the domain and still conform to what EF can understand. The only real way around that is implementing your own expression parser which is really, really not worth it. :)

I like for Repository to receive DbContext, and to very generically do the repository ations on their types, i.e. Get<T>, Single<T>, AddOrUpdate<T>, Delete<T> or whatever, some or all of which predicated. The trick is to then conjure up an appropriate DbSet<T> at the moment it is required, I keep mine in an IDictionary<Type, IListSource> collection for example, and only generate them as I need them. In EF parlance, I don't know how kosher that is, per se; the trick is, I think, to negotiate an apporpriate navigation bridging the gap from domain instances to EF entities, that are subsequently marked for appropriate Add, Update, or Delete. Which is easy enough to facilitate from domain with things like:

interface IModel { bool IsDeleted { get; set; } } interface IModel<TId> : IModel { TId Id { get; set; } // As a function of Id, usually. bool IsPersistent { get; } } 

Along these lines, at any rate. Then a given AddOrUpdate<T> may receive any such IModel and conduct the appropriate set of navigations.

Of course the trick is to inject the domain specific navigation, perhaps as a callback to the IRepository, such that it can do so in a truly and properly inversion of controlled manner, and keep repository very, very generic and reusable.

Then there is the matter of operating whether in a disconnected environment. Mine generally is, I get the set of data, and discard the repository, keep my database clean from connections. So then I must re-attach instances during that negotiation process, navigating to do the correct updates.

Other thoughts, nuggets, pearls?