存储库模式适用于实体框架 [关闭]

Question

一个人说不需要为实体框架使用存储库模式。他给出了一些理由，例如：

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

它不会变得多余吗？ 谢谢

Answer 1

ORM (EF) 和 Repository 模式是两个非常不同的东西，非常被许多开发人员滥用。 EF 确实实现了 UoW（使用真正的 UoW 的 Db 事务），但它没有实现存储库模式。 永远，永远，永远，永远！

EF 是在关系数据库之上模拟 OOP 数据库的数据访问对象。存储库模式抽象了 any 持久性细节。仅仅因为你有一个集合，这并不意味着它是一个存储库。存储库使用 ORM。此外，您不告诉存储库如何 完成其工作 (IQueryable)，您只告诉 您希望从中获得什么。 EF 像使用表一样使用对象（因为它们确实表示表及其关系），存储库以整个概念处理业务对象（可以存储在一个或 10 个表中） ORM 关心数据，存储库关心一致的概念价值观。

使用 ORM 作为存储库违背了模式的目的，即抽象持久性细节。它确实适用于简单的 CRUD 应用程序，您只处理数据结构并且您不关心抽象的东西，但就是这样。对于更复杂的事情，您需要一个正确的存储库模式，它永远不会暴露 ORM 或任何其他数据库访问细节。

在使用 ORM 的简单应用程序中，存储库不会带来太多价值，在这种情况下，您可以跳过它。似乎许多开发人员只在简单的应用程序上工作，他们错误地认为 ORM 就足够了。或者更糟糕的是，他们认为他们正在做 DDD，而实际上他们使用 DDD 术语进行 CRUD。然后他们最终得到了令人厌恶的巨大数据结构，这似乎模仿了关系数据库模式。

使用真正的存储库模式，您不知道也不关心任何持久性。你只知道有一种叫做持久性的东西，仅此而已。而已。它可能是关系数据库、文档数据库、键值存储或外部服务。但只有存储库实现知道这一点，应用程序的其余部分只知道一个名为存储库的神奇事物，它保存/获取对象。

了解存储库的角色是一个设计问题，不幸的是，许多开发人员只专注于编程并且不擅长正确的设计（他们将所有内容都视为 CRUD/事务脚本）。

什么是大中型项目的行业标准？

没有。这取决于你想要从你的应用程序中得到什么。