一个人说没有必要为实体框架使用Repository模式。他给出了一些理由：
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.
我无法找到正确的文章，讨论EF已经实现了存储库模式。所以，如果有任何文章，请让我知道该网站。
如何说出DbContext is UOW和dbset is repository pattern。我正在寻找一个很好的教程，解释DbContext如何作为工作单元工作，dbset是存储库模式。
如果EF已经具有UoW和Repository模式，那么本文为什么要编写额外的代码来开发另一个存储库模式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
不是多余的吗？ 感谢
答案 0 :(得分：1)
ORM（EF）和Repository模式是2个非常不同的东西，很多开发人员误用了 。 EF确实实现了UoW（使用Db事务，这是真正的UoW），但它没有实现存储库模式。 永远，永远，永远，永远！
EF是数据访问对象，它在关系数据库之上模拟OOP数据库。存储库模式抽象任何持久性详细信息。仅仅因为你有一个集合，这并不意味着它是一个存储库。存储库使用 ORM。此外，您不会告诉存储库如何来完成其工作（IQueryable），您只能告诉 您想要的工作。 EF使用对象就好像它是表（因为它们确实代表表及其关系），存储库处理业务对象，如整个概念（可以存储在一个或10个表中）ORM关心数据，存储库关心一致的概念价值。
使用ORM作为存储库会破坏模式的目的，即抽象持久性细节。它适用于简单的CRUD应用程序，在这些应用程序中，您只处理数据结构，而且您并不关心抽象内容，但这就是它。对于任何更复杂的事情，您需要一个适当的存储库模式，它永远不会暴露ORM或其他任何数据库访问细节。
存储库在使用ORM的简单应用程序中没有带来多大价值，在这种情况下，您可以跳过它。似乎许多开发人员只在简单的应用程序上工作，他们错误地认为ORM就足够了。或者更糟糕的是，他们认为他们正在使用DDD，而实际上他们使用DDD术语进行CRUD。然后他们最终得到了巨大的数据结构可憎，似乎模仿了关系数据库模式。
使用真正的存储库模式，您不会知道并且不关心任何持久性。你只知道那里有一种称为持久性的东西，但就是这样。而已。它可能是关系数据库，文档数据库，键值存储或外部服务。但只有存储库实现知道这一点，应用程序的其余部分只知道一个名为存储库的神奇东西，它可以保存/获取对象。
了解存储库的角色是一个设计问题，不幸的是，许多开发人员只关注编程和适当设计（他们将所有内容视为CRUD / transact脚本）。
中型或大型项目的行业标准是什么？
没有。这取决于你的应用程序你想要什么。