According to MSDN, DbContext
is defined as:
Represents a combination of the Unit-Of-Work and Repository patterns and enables you to que
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.I know it's too late
For Unit-Of-Work : When you're pulling data in and out of a database, it's important to keep track of what you've changed.Similarly you have to insert new objects you create and remove any objects you delete.
You can change the database with each change to your object model, but this can lead to lots of very small database calls.
A Unit of Work keeps track of everything you do during a business transaction that can affect the database.
For Repository Pattern: It's an isolate business domain from database.
Read the book (PEAA)