0

If yes, then we are done... no need to design and implement repos and unit of work when using EF (with DbContext)

Maybe I missed something, but for me DbContext implements a perfect UnitOfWork (well the interface is missing... :-( ) and its .Set are the generic repos for entity T.

Why then people keep implementing repos what are using/have a context, and implement unit of works what are using/have one of more repos? They implementing a design patter using an implementation of the same design pattern.

(I know: EF DbContext is not implementing a usable interface which fits to UnitOfWork/Repo pattern, but beside this, missed I something?)

Thx in advance

g.pickardou
  • 32,346
  • 36
  • 123
  • 268
  • 1
    possible duplicate of [Generic Repository With EF 4.1 what is the point](http://stackoverflow.com/questions/5625746/generic-repository-with-ef-4-1-what-is-the-point) – Gert Arnold Nov 12 '13 at 09:32

2 Answers2

2

Yes they are the implementation of unit of work and the repository pattern.
I think the only case where you need to use your own repositories or unit of work is when you are planing to separate your data access logic from the repository level . That means if you are going to use some another way of accessing database (like Nhibernate) later ,then it is easy to have your own repository layer.

And also if you need to have another type of datasources not only the entity framework, then it is better to have an abstraction layer for your data access like this.

Jayantha Lal Sirisena
  • 21,216
  • 11
  • 71
  • 92
0

You are right.

But people are implementing their custom versions on top of already existing if they miss some features (for example DbSet is too generic repository with lack possibilities for query reuse (for example with specification pattern)).

Oleksandr Kobylianskyi
  • 3,281
  • 20
  • 33