ASP.net 5和EF7中是否不再需要存储库？

我在github上向EF团队发布了一个问题。我得到了一个答复，说最好在这里提出这个问题，所以我将其复制并粘贴到此处作为链接，以便其他人可以在GitHub上看到一些答复。

问题：我正在做一些研究，有人指出DBContext类的第24行指出

DbContext是工作单元和存储库模式的组合。

这是否意味着我们不再需要将EF抽象到存储库，然后使用and Interface将其注入Controller中？

Github上的原始帖子：https : //github.com/aspnet/EntityFramework/issues/4899

我问这个问题的原因是，我似乎进入了一个即时状态，即在存储库中添加了很多方法，例如GetById，GetByName，GetWithIncludesABC，GetWithIncludes123等。这似乎在困扰着我

如果您要向存储库中添加方法，例如

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

然后，最好转移到服务层，并让服务层直接使用EF。EF已经具有与上述方法类似的功能，您将无休止地进行复制。

服务层公开业务域方法，并使用CRUD来实现它们。例如，您可能有一个名为的方法TransferMoney(A, B)，其中A和B正在检查帐户。这使您可以说出业务领域的语言，而服务层则为您处理CRUD。

我可以想到的唯一令人信服的原因是，您可能希望在哪里拥有单独的存储库层，以便您可以模拟该存储库层或替换其他数据源以进行测试。

罗伯特·哈维（Robert Harvey）在回答中说：

我可以想到的唯一令人信服的原因是，您可能希望在哪里拥有单独的存储库层，以便您可以模拟该存储库层或替换其他数据源以进行测试。

这就是为什么存储库模式仍然重要的原因。我也不同意实体框架团队关于实现存储库模式的主张。实体框架仍然非常依赖于数据库。存储库模式的整个目的是将应用程序中使用的确切持久性机制解耦和抽象化，以使数据访问实现中的任何内容都不会泄漏到存储库层之外。

如果您在“存储库”之外使用EF查询API，例如在某种服务对象中使用，我会说您正在破坏模式。

现在，如果泄漏到其他代码中的数据库之类的功能不是灾难性的问题，并且可以保证将来不需要将某些CRUD操作移至Web服务，那么直接使用EF就可以了。好。

基本上，实体框架在存储库模式中代替了网关对象。我不将其视为存储库本身。

似乎不需要存储库-Microsoft在其示例后端微服务应用程序中不使用它们：

https://github.com/Microsoft/BikeSharing360_BackendServices

样本BikeSharing应用程序显示在Connect（）上；事件（我认为它可以用作API项目的模板）：

https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/