Alternative to Unit of Work + Repository for Dbcontext sharing

Asked

Viewed 79 times

0

I’ve seen many times people talking that it makes no sense to use Unit of Work + Repository with Dbcontext Work unit (Unit of Work) with repository

Supposedly it would be "more certain" to use Dbcontext directly in a layer such as service? like: 

public class SomeService
{
   public void SomeSaveMethod(Obj obj)
   {
       DbContext.Set<TEntity>().Add(obj); 
       DbContext.SaveChanges(); 
   }
}

This approach does not seem better to me, as it makes the service class less cohesive and creates a dependency with implementation. So what are the other alternatives? I use Repository as a way to hide the implementation by taking advantage of Heritage for CRUD and Uow to share Dbcontext (which is injected by DI in Uow).

c# entity-framework repository
  • 1

    This is very relative, it depends on the architecture you are deciding to use. But since you mentioned the layers, if you wanted to separate them by layers, I would make a unique data access, containing Uow. Leaving the service layer unique to the rules of business, and through the service would call the repository.

  • This is exactly how I’ve been developing my projects! Actually the question is more because I read several people who seem to have a certainty on the subject (of not using Unit of Work + Repository +Dbcontext), and so far I do not understand where it comes from....

1 answer

1

Architecture is a complicated and controversial theme. There is no "silver bullet" that solves everything. Many people are against using a repository when using a ORM because it offers many facilities in accessing and operating data and creating a repository causes repetitive printing. I don’t agree with this approach because you’re delegating all your data manipulation to a framework. This may cause future performance-related problems with large, illegible, and difficult to debug Lambda / large queries. There are other factors that motivate using the repository and other layers in a system that is the writing of tests. If you, for example, put data access and business rule resolution in the domain layer you will probably write large and complex methods making it impossible to write unit tests. A classic layered web application usually contains the following layers (remember that there may be several other architectural solutions):

User Interface (User Interface)

Layer where user iteration occurs

Application ()

Another polemical layer. In it you treat your interface rules as, for example, turn a Model into Viewmodel and vice versa.

Domain ()

In this layer you solve the business rules of the application how to perform certain calculation according to the data informed by the user, calculate the percentage to debit from a sale etc.

Repository ()

Here you only treat data access. The domain layer "delivers" the "ready" domain objects so you can only perform database operations.

This is just one example of architecture that is very common, but as I said in the beginning there is no silver bullet for everything. Before starting development, any system should try to understand the requirements of the application to create an adhering architecture that meets the needs of the application, be easy to understand and develop. Remember that we have several other types of architecture as based on microservices, messaging among others. Take a look in this talk that talks about the architecture of Stackoverflow.

Browser other questions tagged c# entity-framework repository

You are not signed in. Login or sign up in order to post.