我对存储库模式和实体框架有点困惑。
在this answer 中，我了解到，在实体框架之上创建存储库是不好的，原因如下：
UnitOfWork
Repository 模式用于将数据库从业务逻辑中抽象出来，Entity Framework 就是这样做的我们应该使用服务，而不是在 EF 之上创建存储库。
现在的问题：
如果我出于性能原因决定用存储过程调用（如mentioned here）替换一些 Linq 查询，那会怎样？这个答案建议使用某种存储库模式。
如果我直接在服务层调用存储过程，感觉很脏，因为数据库将不再从业务逻辑中抽象出来。
如何抽象存储过程调用？还是可以从Service层调用？
【问题讨论】：
标签： c# sql entity-framework linq repository-pattern
在 EF 之上拥有一个 repo 不好的原因是，在许多情况下，开发人员还暴露了 IQueryable，这违背了该模式的目的。您当然可以拥有一个使用 EF 作为内部实现细节的存储库（顺便说一句，这是一项服务）。
Repository 和 EF 之间的关系是 Repository 可能使用 EF，但客户端（使用 repo）不应该意识到这一点。 EF 不是存储库，虽然它可以作为一个存储库使用，但它是开发人员忽略重点的又一个案例。
在 CRUD 应用程序中直接使用 EF 是可以的，不用假装你在使用存储库模式，那些应用程序并不真正需要它。
在您的情况下，存储库实现应该允许您按照您认为合适的方式对其进行更改，因为接口不应该受到影响；这就是为什么存储库接口仅适用于业务模型定义的业务对象。
在适当的架构中，您不会直接执行 linq 或调用 SProcs，因为这些是持久层的详细信息。应用程序的其余部分不知道它们。您可以让存储库、查询服务等（作为接口）与调用层已知的概念（业务对象、视图模型、读取模型）一起工作，并且只有这些服务的实现才知道 EF 或 SPRocs。
【讨论】：