實體框架：在共享程序集中提供DbContext和ObjectContext API

Question

我一直在構建一個具有中央數據庫的系統。多個應用程序將運行在數據庫之上。因此，我沒有必要維護多個實體框架圖和設置，而是將所有實體框架類放入一個專用程序集中，該程序集將在所有使用數據庫的解決方案中共享。到目前爲止，這一切都很好。

目前，我已經使用實體框架生成派生的DbContext。

但是，在某些情況下，我發現擁有一個對象上下文對於我試圖完成的任務來說會更方便。一個例子是參考實體的一個非常簡單的（鍵 - 值）緩存解決方案。我使用名稱「參考實體」來描述比提供字符串值或查找更少功能的實體。在這種情況下，從DbContexts緩存實體對象很麻煩，因爲您不能簡單地將它們添加到另一個DbContext - 如果需要，您必須附加它。 （這是我頭頂的一個例子，所以不要太在乎它的摳圖！）。

因此，我認爲可能值得在我的共享程序集中提供DbContext API和ObjectContext API。這樣，大會的用戶可以使用他們認爲更方便的任何一種。顯然，我將不得不將它們分成兩個非常獨立的命名空間，以避免類命名衝突，但是我認爲應該有一個Company.Tech.Database.DBContext命名空間和Company.Tech.Database.ObjectContext。

有誰認爲這是一個壞主意？好主意？我的理解是，雖然DbContext比較新，但它不一定比ObjectContext「更好」，它只是提供了一個可能被認爲更簡單但不依賴於用例的不同API。在這種情況下，不會提供這兩種API是好事嗎？

Answer 1

你不能嚴格說是好還是壞想法，因爲沒有這樣的事情，這完全取決於你的情況。但是我可以給你一個建議，你可以看到DbContext在其中封裝了一個ObjectContext，並且調用該ObjectContext上的方法來完成它的工作，所以它提供了一個簡化的ObjectContext版本。當然，這意味着您仍然可以訪問包裝的ObjectContext實例，如var ctx = ((IObjectContextAdapter)db).ObjectContext;，其中db是您的DbContext子類，所以不是提供兩個可能會讓客戶端感到困惑並需要更多維護的不同API，而是使用所需的其他方法來增強您的DbContext子類爲了性能，這些額外的方法可以利用ObjectContext。這樣您將擁有更少的代碼來維護和統一的API。