0

one guy said no need to use Repository pattern for entity-framework.he gave some reason like :

The single best reason to not use the repository pattern with Entity Framework? 
Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) 
and each DbSet is the repository. Implementing another layer on top of this is not only redundant, 
but makes maintenance harder.

i just unable to find right article which discuss EF already implement repository pattern. so if any article exist then please make me aware of that site.

how one can say DbContext is UOW and dbset is repository pattern. i am looking for a good tutorial which explain how DbContext is working as unit of work and dbset is repository pattern.

if EF already has UoW and Repository pattern then why this article show to write extra code to develop another repository pattern http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

is it not getting redundant ? thanks

Mou
  • 15,673
  • 43
  • 156
  • 275
  • This is both a largely opinionated and constantly debated topic, with multiple (closed) posts regarding this topic. This site's format does not allow for this type of discussion. – Claies Sep 14 '15 at 14:54
  • 1
    Your going to find lots of debate on the issue. See this: http://programmers.stackexchange.com/questions/180851/why-shouldnt-i-use-the-repository-pattern-with-entity-framework – Steve Greene Sep 14 '15 at 14:55
  • what is industry standard for mid or big size project? – Mou Sep 14 '15 at 15:01
  • There is no debate. Repository and ORM are 2 different things with 2 different purposes. There is a the right way of using them and the wrong (anti-pattern) way. Many devs are using the wrong way. – MikeSW Sep 26 '15 at 15:24
  • possible duplicate of [NOT using repository pattern, use the ORM as is (EF)](http://stackoverflow.com/questions/14110890/not-using-repository-pattern-use-the-orm-as-is-ef) – jgauffin Sep 26 '15 at 15:28

1 Answers1

1

The ORM (EF) and Repository pattern are 2 very different things that are very misused by a lot of devs. EF does implement the UoW (using a Db Transaction which is the real UoW) but it doesn't implement the repository pattern. Never, ever, ever,never!

EF is data access object which simulates a OOP db on top of a relational db. The repository pattern abstracts any persistence details. Just because you have a collection, that's doesn't mean it's a repository. A repository uses an ORM. Also, you don't tell a repository how to do its job (IQueryable), you tell only what you want from it. EF uses objects as if it were tables (because they do represent tables and their relationships), the repository deals with business objects as in whole concepts (which can be stored in one or 10 tables) The ORM cares about data, the repository cares about consistent concept values.

Using an ORM as a repository defeats the purpose of the pattern i.e abstracting persistence details. It does work for simple CRUD apps where you only deal with data structures and you don't care about abstracting stuff, but that's it. For anything more complex, you need a proper repository pattern which never exposes the ORM or whatever other db access detail.

The Repository doesn't bring much value in simple apps which use an ORM and in those cases you can skip it. It seems that many devs only worked on simple apps and they mistakenly think that the ORM is enough. Or worse they think they're doing DDD when in fact they do CRUD using DDD terms. And then they end up with huge data structures abominations which seems to mimic a relational database schema.

With a true repository pattern, you don't know and don't care about anything persistence. You only know there's something called persistence but that's it. Nothing more. It might be a relational database, a document db, a key value store or an external service. But only the repository implementation knows this, the rest of the app only knows about a magic thing called repository which saves/gets objects.

Understanding the role of a repository is a design matter and unfortunately lots of devs focus only on programming and suck at proper design (they treat everything as CRUD/transact script).

what is industry standard for mid or big size project?

There is none. It depends on your what you want from your app.

MikeSW
  • 16,140
  • 3
  • 39
  • 53