Alternative to Unit of Work + Repository for sharing DbContext [closed]

Question

Alternative to Unit of Work + Repository for sharing DbContext [closed]

Navigation

#1 by (1 votes)

0

I've seen people saying several times that it does not make sense to use Unit of Work + Repository with DbContext Unit of Work with repository

Is it supposed to be "more secure" to use DbContext directly on a service layer? like:

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

This approach does not seem any better, since it leaves the service class less cohesive and creates a dependency on the implementation. So what are the other alternatives? I use the Repository as a way to hide the implementation by taking advantage of Inheritance for CRUD and UoW to share DbContext (which is injected by DI into UoW).

c# entity-framework repository

asked by anonymous 07.10.2018 / 18:51

1 answer

Custom validation function html5 Run Event TextBox c # WPF

score 1 · Answer 1

Architecture is a complicated subject and even controversial. There is no "silver bullet" that solves everything. Many people are against using repository when using some ORM because it offers many facilities in access and operations with data and creating a repository causes the reprint impression. I do not agree with this approach because you are delegating all of your data manipulation to a framework. This may cause performance-related problems with large linq / lambda queries, unreadable and difficult to debug. There are other factors that motivate you to use the repository and other layers in a system that is writing tests. If you, for example, put data access and business rule resolution on the domain layer, you're probably going to write large, complex methods, making unit-writing impossible. A classic layered web application usually contains the following layers (remember that there may be several other architectural solutions):

User Interface

Layer where iteration occurs with the user

Application (application)

Another polemic layer. In it you treat your interface rules, such as transforming a Model into ViewModel and vice versa.

Domain

In this layer you resolve the business rules of the application such as making a certain calculation according to the data reported by the user, calculate the percentage to be debited from a sale etc.

Repository

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

This is just an example of architecture that is very common, but as I said at the beginning there is no silver bullet for everything. Before beginning development, any system should understand the requirements of the application to create an adherent 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 at in this lecture that talks about architecture of Stackoverflow.