Is it a good idea to wrap my DbContext in a Unit of Work class?

I am trying to implement the Work of Work / Repository pattern in an MVC web application.

Since DbContext itself is a unit of work, I want to mix it with my own UOW for testing and decoupling purposes (untie the business layer from EF). Is it a good idea to just wrap my DbContext inside a UOW class like this?

Example:

Short code for clarity

 public interface IUnitOfWork { void Save(); } public MyContext : DbContext { // DbSets here } public UnitOfWork : IUnitOfWork { public MyContext myContext { get; set; } void Save() { myContext.SaveChanges(); } } 

Then I would call an instance of UnitOfWork to perform data operations.

Thank you very much in advance: -)

+4
source share
1 answer

Depending on what you are trying to accomplish.

I want to create an abstraction layer between the Entity Framework and your business logic, then yes, this is a good idea. But then you have to do a complete abstraction, meaning that your repository classes cannot expose IQueryable<T> .

If you are not creating a complete abstraction, I see no reason to transfer the DbContext to a working class unit.

+4
source

Source: https://habr.com/ru/post/1496556/


All Articles