实体框架是存储库吗答案

【问题标题】：Is Entity Framework a repository实体框架是存储库吗
【发布时间】：2019-12-04 16:28:24
【问题描述】：

在应用层的意义上，我很难弄清楚如何放置实体框架DbContext。在我看来，它旨在替换存储库层，但另一方面，它实际上并不像更基本的存储库那样工作，它是通过接口实现的，便于以后交换。

所以我在 service 和 repository 层（例如this post）上发现了很多好帖子，但它似乎没有回答实体框架适合的地方在这个模式中。

我应该在 Entity Framework 之上添加一个存储库层，还是应该在我的服务中使用 DbContext 代替存储库？

【问题讨论】：

这是一本好书：blog.zhaytam.com/2019/03/14/generic-repository-pattern-csharp
这里有一个反论点：thereformedprogrammer.net/…
@Jazb 了解反论点，但我觉得存储库仍然可以增加价值，因为您不需要重复自己。如果没有存储库，您会发现自己一直在处理 id，并重复 savechanges() 等......存储库可以简单地替换单个方法。
@GlennvanAcker - 是的，没有对错 - 只是意见和偏好
EF 既是存储库又是 UoW。查看更多详情here。

【解决方案1】：

您需要问自己为什么要抽象出数据访问层。

答案通常是：

许多人认为第二个论点是完全错误的，因为：

总而言之，我倾向于同意 可测试性 应该是您的主要关注点，对于 EntityFramework，您可以：

并且，回答您的问题标题：是的。 DbContext 是已经在充当存储库了。

【讨论】：

很好，谢谢。我正在使用 EF Core，最近开始摆弄InMemory 提供程序，这实际上是我提出这个问题的原因。在我看来，微软的这一举措似乎取代了传统的存储库模式（这当然会使他们受益，因为人们会坚持使用他们的数据库）。

【解决方案2】：

EF 不是一个层，它是一种数据访问技术。

EF 调用应该写在存储库中，作为服务层的抽象，这样服务层就不会关心数据是存储在数据库中还是其他地方。

【讨论】：

我同意这一点。但是后来 Entity Framework 引入了InMemory，这让我很少觉得我需要再模拟存储库了。所以在我看来，Entity Framework 正试图取代更“正常”的存储库，如果你明白我的意思吗？
这不仅仅是嘲笑。您可能有一个存储库来访问微服务以存储其数据，或者可能与大型机通信，谁知道，并且您的系统可能需要调用多个第三方服务。存储库的意义在于，服务层开发人员不必关心这些东西是如何工作的。他们只是担心编写与存储库公开的抽象交互的业务规则。