體系結構，所以你可以交換SQL的實體框架，反之亦然

Question

我一直在努力與此相似的一段時間。如果你的架構這樣的..

Project.Domain 
- Entities 
- Repositories interfaces Project.Persistence.EF 
- Repositories 
- ContextProvider 
- etc.. 
Project.Persistence.SQL 
??? 
Project.Tasks 
... 
Project.Presentation 
... 

有了一個IoC，你幾乎可以改變任何成分爲他人組件..這裏最重要的接口，它是關係到的問題是IRepository（通用）位於域。只有定義，而不是執行。

我一直在尋找的主要問題是如何我可以在幾乎沒有時間切換爲EF SQL？

如果你看看倉庫接口..它的目的顯然與上下文工作。

public interface IRepository<T> where T : class 
{ 
    void Add(T entity); 
    void Delete(T entity); 
    T GetById(long Id); 
} 

我怎麼能那麼做這個倉庫來使用SQL實現也工作，所以我可以使用國際奧委會選擇愨EF和SQL？

當然，我可以製作IRepositorySQL和IRepositoryEF，但是我不能爲此使用IoC ...並再次卡住。

任何意見或建議或方式來做事？

謝謝。

Answer 1

在抽象數據層的通用解決方案的要點是要扔掉所有的特定功能：

• 你會扔掉LINQ，因爲它是一些ORM的特定功能
• 你會扔掉延遲加載因爲它是具體的一些ORM
• ，你會扔掉更改跟蹤或實現自己的更改跟蹤
• 等

你也會扔掉通用的方法。通用方法僅用作特定存儲庫的基本接口。所有特定功能只會在存儲庫中使用，並且使用存儲庫時不得有任何副作用，因爲在使用不同的實現時不必發生這些副作用。

應該由通用的解決方案可以提供任何高級功能，必須從頭開始實施，正確解釋裏面具體實施。這導致了一系列模式，例如Repository，Unit of Work或Specification。如果您不提取高級功能，您將只有功能設置等於大多數有限特定實施方案的解決方案。

因這應該只有當它是絕對必要的=這是主要產品的要求之一來完成。否則它是waste of time and money。