为什么要使用Repository Pattern或者请向我解释一下？

Question

我正在学习存储库模式,正在阅读存储库模式,包括实体框架4.1和代码优先 和通用存储库模式 - 实体框架,ASP.NET MVC和单元测试三角 关于它们如何使用实体框架实现存储库模式.

话

•从上层隐藏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)
{
...
}

这也是一个存储库模式吗？

假人的解释会很棒:)

Answer 1

我不认为你应该这样做.

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

我在博客文章中谈到过这个问题: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

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

Answer 2

一件事是增加可测试性并与基础持久性技术松散耦合.但是每个聚合根对象也有一个存储库(例如,一个订单可以是聚合根,它也有订单行(不是聚合根),以使域对象持久性更加通用.

它还使管理对象变得更加容易,因为当您保存订单时,它还会保存您的子项(可以是订单行).

Answer 3

这张照片让人很容易理解

Answer 4

将您的查询放在一个中心位置也是一个优势；否则您的查询会分散在各处并且更难维护。

你提到的第一点：“隐藏EF”是一件好事！例如，保存逻辑可能很难实现。有多种策略最适用于不同的场景。特别是在保存相关实体中也有变化的实体时。

使用存储库（与 UnitOfWork 结合）也可以集中这个逻辑。

这里有一些视频有很好的解释。