I am trying to implement Unit of Work/Repository pattern in my 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 (decoupling business layer from EF). Is it then a good idea to just wrap my DbContext
inside an UOW class like the following?
Code reduced 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 UnitOfWork
instance to perform data operations.
Thanks a lot in advance :-)
I depends on what you are trying to accomplish.
I you want to create an abstraction layer between Entity Framework and your business logic, then yes, it's a good idea. But then you have to do a complete abstraction meaning that your repository classes can not expose IQueryable<T>
.
If you don't create a complete abstraction, then I do not see any reason to wrap the DbContext in a unit of work class.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With