我对存储库模式和实体框架之间有点混淆。没有存储库模式的实体框架中的存储过程
在this answer，我已经学会了，它是坏的就这些原因实体框架的顶部创建一个存储库：
UnitOfWorkRepository模式用于将数据库从业务逻辑中抽象出来，而实体框架的作用是：而不是在EF之上创建一个存储库，我们应该使用一个服务。
现在的问题：
是什么，如果我决定性能的原因与存储过程调用替换一些Linq查询，像mentioned here？这个答案建议使用某种存储库模式。
感觉很脏，如果我直接在服务层调用存储过程，因为数据库将不再从业务逻辑中抽象出来。
我将如何抽象存储过程调用？或者可以，从服务层调用它？
在EF之上回购很糟糕的原因是，在很多情况下，开发人员还暴露了IQueryable，这些都破坏了模式的目的。您当然可以拥有一个使用EF作为内部实现细节的存储库（这是一种服务，btw）。
Repository和EF之间的关系是Repository可能使用EF，但客户端（使用repo）不应该意识到这一点。 EF是不是一个存储库，虽然它可以作为一个使用，但它是开发人员忽略了这一点的又一例。
可以直接在CRUD应用程序中使用EF，而无需假装使用Repository模式，这些应用程序并不需要它。
在你的情况下，存储库实现应该允许你改变它，但你认为合适，因为接口不应该受到影响;这就是为什么存储库接口只能与业务模型定义的业务对象一起工作的原因。
在正确的体系结构中，您不会直接执行linq或调用SProcs，因为这些是持久层详细信息。该应用程序的其余部分不知道他们。您可以使存储库，查询服务等与调用层已知的概念（业务对象，视图模型，读取模型）一起工作（作为接口），并且只有那些服务的实现知道EF或SPRoc。