At my current job I have implemented the Repository/UoW patterns on top of EntityFramework and DbContext. The only valid reasons I have found for this would be if you didn’t want to depend on one particular ORM solution. I just wanted to see if anyone ever did this and, half way through the project (say, a year down the road) decided: “Geez, I’m glad I implemented that Repository Pattern because I need to switch from EntityFramework to NHibernate.” Aside from crud and some basic queries with joins (using LINQ) I feel this extra layer of abstraction is annoying since you have to create the table in the database, write a repository, write a service (if you’re going for the typical 3 tiered arch) and the necessary front end like a controller and views.
Update:
Would like to know if anyone has switch ORM’s on a project before and why?
You do not have to do this. I am not aware of any project that actually switched, and switching will actually include a lot of work anyway.
If you read Ayende’s blog you will find a lot of points against repositories.
The only reason to do this is when you are developing a framework that can be used with several ORMs based on specific use case.
Moreover, having a repository per table is very wasteful of developer’s time.
Even if you go with repositories, having one generic repository with some entity-specific extensions should be more than enough.
Having said all this, I still do use repositories, mostly because I dislike direct references to third-party libraries in unrelated code. But this is a question of preference, and not a best practice I can prove.