According to MSDN, DbContext
is defined as:
Represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit.
Since DbContext
implements the Unit of Work and Repository patterns, then why does this ASP.NET tutorial and other resources that I have found on the Internet demonstrate the use of DbContext
with custom implementations of the Unit of Work and Repository patterns? Isn't this redundant?
If not, what is the benefit of creating custom implementations of the Unit of Work and Repository layers when using DbContext
? (I can see how this might make sense within a Test project.)
Yes, DbContext
represents a Unit of Work and DbSet
represents a Repository, but some people will create a layer of abstraction over them. Here are some reasons people might do so:
CustomerRepository
might allow adding and updating customers but not deleting them). On the other hand, it enables a client developer to easily recognize available operations for certain entities. In other words, they create repositories with naming conventions and interfaces that are compatible with the domain language.ICustomerRepository
interface with three methods. Then I can easily mock that up instead of mocking an IDbSet<Customer>
with too many methods.DbContext
and DbSet
. They just use them directly and it is perfectly valid to do so.