Entity framework 存储库模式解决了什么具体问题？

（注意：我的问题与三个月前提出问题的人的担忧非常相似，但从未得到回答。）

我最近开始使用MVC3+实体框架，我一直在阅读最佳实践是使用存储库模式来集中对DAL的访问。这还附带了一些解释，说明您希望将DAL与域（尤其是视图层）分开。但在我看到的示例中，存储库只是（或似乎是）返回DAL实体，即在我的示例中，存储库将返回EF实体

所以我的问题是，如果存储库只返回DAL实体，那么它有什么好处？这不是增加了一层复杂性，不能消除在层之间传递DAL实体的问题吗？如果存储库模式创建了一个“DAL的单一入口点”，那么它与上下文对象有何不同？如果存储库提供了检索和持久化DAL对象的机制，那么这与上下文对象有何不同

此外，我至少在一个地方读到，工作单元模式将存储库访问集中化，以便管理数据上下文对象，但我也不明白这为什么重要

---

我98.8%确定我在这里遗漏了什么，但从我的读数中我没有看到。当然，我可能只是没有读到正确的来源…：\

实体框架的

DbContext

基本上类似于一个存储库（以及一个工作单元）。你不必在简单的场景中把它抽象出来

存储库的主要优点是，您的域可以是无知的，并且独立于持久性机制。在基于层的体系结构中，依赖项从UI层向下通过域（或通常称为业务逻辑层）指向数据访问层。这意味着UI依赖于BLL，而BLL本身依赖于DAL

在更现代的体系结构中（通过域驱动设计和其他面向对象的方法传播），域应该没有向外指向的依赖关系。这意味着UI、持久性机制和其他一切都应该依赖于域，而不是相反

然后，存储库将通过其在域内的接口表示，但其具体实现在域外的持久性模块中。这样，域只依赖于抽象接口，而不依赖于具体实现

这基本上是面向对象与体系结构级别的过程编程

另见

---

存储库的另一个优点是，您可以创建对各种数据源的类似访问机制。不仅适用于数据库，也适用于基于云的存储、外部API、第三方应用程序等。

如果您有多个数据源，并且希望使用一致的编码策略访问这些数据源，这将非常有用

例如，您可能有多个EF数据模型，一些数据使用传统的ADO.NET和存储过程进行访问，一些数据使用第三方API进行访问，一些数据从位于您扫帚柜中一层灰尘下的Windows NT4服务器上的Access数据库进行访问

您可能不希望您的业务层或前端层关心数据来自何处，因此您可以构建一个通用存储库模式来访问“数据”，而不是访问“实体框架数据”

---

在这种情况下，您的实际存储库实现将彼此不同，但调用它们的代码不会知道区别。

没错，在这些简单的情况下，存储库只是DAO的另一个名称，它只带来一个价值：您可以将EF切换到另一种数据访问技术。今天您正在使用MSSQL，明天您将需要一个云存储。或者使用micro orm代替EF，或者从MSSQL切换到MySql

在所有这些情况下，最好使用存储库，因为应用程序的其余部分不会关心您现在使用的存储

还有一种有限的情况是，您可以从多个来源（db+文件系统）获取信息，repo将充当facade，但它仍然是DAO的另一个名称

---

“真实”存储库只有在处理域/业务对象时才有效，对于不会更改存储的以数据为中心的应用程序，仅使用ORM就足够了。

考虑到您的场景，我只需选择一组接口来表示需要从数据层返回的数据结构（您的域模型）。然后，您的实现可以是EF、原始ADO.Net或任何其他类型的数据存储/提供程序的混合体。这里的关键策略是将实现从直接消费者（您的域层）抽象出来。当您想要对域对象进行单元测试，并且在不太常见的情况下—完全更改数据提供程序/数据库平台时，这非常有用

你应该，如果你还没有考虑，使用一个As，因为它们非常容易地解决了你的解决方案的松散耦合。我个人更喜欢

域层应该封装您的所有业务逻辑—问题域的规则和需求，可以直接被MVC3 web应用程序使用。在某些情况下，引入位于域层之上的存储库是有意义的，但这并不总是必要的，而且对于简单的web应用程序来说可能过于苛刻。

我认为“存储库”一词通常被认为与Martin Fowler的书中描述的“存储库”一样

存储库在域和数据映射层之间进行调解， 作用类似于内存中的域对象集合。客户端对象 以声明方式构造查询规范并将其提交给 满足的知识库。对象可以添加到或从中删除 存储库可以通过简单的对象集合