45

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.)

DavidRR
  • 18,291
  • 25
  • 109
  • 191
Usman Khalid
  • 3,032
  • 9
  • 41
  • 66

2 Answers2

76

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:

  • Maybe they don't want their project tightly coupled to Entity Framework and its architecture. So, they hide Entity Framework behind those abstractions so they can substitute Entity Framework for any other ORM without any modification to the interface of the data access layer.
  • They use repositories to make it clear which operations are allowed for certain entities. (For example, 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.
  • Moving database-related operations to repositories allows you to intercept those operations and perform logging, performance tuning or any other operation you want.
  • Some do it to make testing easier. Say I have an ICustomerRepository interface with three methods. Then I can easily mock that up instead of mocking an IDbSet<Customer> with too many methods.
  • Finally, there are many who do not create an abstraction over DbContext and DbSet. They just use them directly and it is perfectly valid to do so.
DavidRR
  • 18,291
  • 25
  • 109
  • 191
Ibrahim Najjar
  • 19,178
  • 4
  • 69
  • 95
  • IMO, repository design pattern on top of EF is not necessary but nice to have on enterprise application, so that make implementation clear by contracts (Interfaces). However unit of works on top of EF may think twice, abstraction of abstraction is over work. Some peoples use UOW to manage the DBContext transaction scope ( rollback(), commit() ) which is very wired to me. – Cheung Jun 20 '22 at 04:40
4

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)

Amer Jamaeen
  • 677
  • 8
  • 16
  • 3
    PEAA is outdated. Pattern implementations are awful in today's standards (explicit thread local storage, unit of work related code inside domain objects etc.). So, one may just get a list of patterns from the book and disregard any example implementations. – Vakhtang Aug 27 '18 at 23:16
  • My thought UOW is about let every Controller contact single dependency by inject UOW via contractor, rather than different repository. And advantage of uow may not because of change tracking of DB. – Cheung Jun 20 '22 at 04:44