我對存儲庫模式和實體框架之間有點混淆。沒有存儲庫模式的實體框架中的存儲過程
在this answer，我已經學會了，它是壞的就這些原因實體框架的頂部創建一個存儲庫：
UnitOfWorkRepository模式用於將數據庫從業務邏輯中抽象出來，而實體框架的作用是：而不是在EF之上創建一個存儲庫，我們應該使用一個服務。
現在的問題：
是什麼，如果我決定性能的原因與存儲過程調用替換一些Linq查詢，像mentioned here？這個答案建議使用某種存儲庫模式。
感覺很髒，如果我直接在服務層調用存儲過程，因爲數據庫將不再從業務邏輯中抽象出來。
我將如何抽象存儲過程調用？或者可以，從服務層調用它？
在EF之上回購很糟糕的原因是，在很多情況下，開發人員還暴露了IQueryable，這些都破壞了模式的目的。您當然可以擁有一個使用EF作爲內部實現細節的存儲庫（這是一種服務，btw）。
Repository和EF之間的關係是Repository可能使用EF，但客戶端（使用repo）不應該意識到這一點。 EF是不是一個存儲庫，雖然它可以作爲一個使用，但它是開發人員忽略了這一點的又一例。
可以直接在CRUD應用程序中使用EF，而無需假裝使用Repository模式，這些應用程序並不需要它。
在你的情況下，存儲庫實現應該允許你改變它，但你認爲合適，因爲接口不應該受到影響;這就是爲什麼存儲庫接口只能與業務模型定義的業務對象一起工作的原因。
在正確的體系結構中，您不會直接執行linq或調用SProcs，因爲這些是持久層詳細信息。該應用程序的其餘部分不知道他們。您可以使存儲庫，查詢服務等與調用層已知的概念（業務對象，視圖模型，讀取模型）一起工作（作爲接口），並且只有那些服務的實現知道EF或SPRoc。