为什么使用存储库模式或者请向我解释一下？

我正在学习存储库模式并正在阅读使用 Entity Framework 4.1 和 Code First 的存储库模式 http://www.codeproject.com/Tips/309753/Repository-Pattern-with-Entity-Framework-4-1-and-C and 通用存储库模式 - 实体框架、ASP.NET MVC 和单元测试三角 http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle关于他们如何使用实体框架实现存储库模式。

Saying

•对上层隐藏EF
•使代码更好地可测试

使代码更好地可测试我确实理解，但为什么要对上层隐藏 EF？

看看他们的实现，似乎只是用查询实体框架的通用方法包装了实体框架。其实这样做的原因是什么？

我假设是为了

1. 松耦合（这就是为什么要对上层隐藏 EF？）
2. 避免为同一查询重复编写相同的 LINQ 语句

我的理解正确吗？

如果我写一个 DataAccessLayer 这是一个有方法的类

QueryFooObject(int id)
{
..//query foo from entity framework
} 

AddFooObject(Foo obj)
{
.. //add foo to entity framework
}
......
QueryBarObject(int id)
{
..
}

AddBarObject(Bar obj)
{
...
}

这也是存储库模式吗？

对虚拟人的解释会很棒:)

我认为你不应该。

实体框架已经是数据库上的抽象层。上下文使用工作单元模式，每个 DBSet 都是一个存储库。在此基础上添加存储库模式会使您远离 ORM 的功能。

我在我的博客文章中谈到了这一点：http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

添加您自己的存储库实现的主要原因是，您可以使用依赖项注入并使代码更易于测试。

EF 开箱即用的测试性不高，但使用可注入的接口制作 EF 数据上下文的可模拟版本非常容易。

我在这里谈到了这一点：http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context

如果我们不需要存储库模式来使 EF 可测试，那么我认为我们根本不需要它。