我一直在構建一個具有中央數據庫的系統。多個應用程序將運行在數據庫之上。因此,我沒有必要維護多個實體框架圖和設置,而是將所有實體框架類放入一個專用程序集中,該程序集將在所有使用數據庫的解決方案中共享。到目前爲止,這一切都很好。實體框架:在共享程序集中提供DbContext和ObjectContext API
目前,我已經使用實體框架生成派生的DbContext。
但是,在某些情況下,我發現擁有一個對象上下文對於我試圖完成的任務來說會更方便。一個例子是參考實體的一個非常簡單的(鍵 - 值)緩存解決方案。我使用名稱「參考實體」來描述比提供字符串值或查找更少功能的實體。在這種情況下,從DbContexts緩存實體對象很麻煩,因爲您不能簡單地將它們添加到另一個DbContext - 如果需要,您必須附加它。 (這是我頭頂的一個例子,所以不要太在乎它的摳圖!)。
因此,我認爲可能值得在我的共享程序集中提供DbContext API和ObjectContext API。這樣,大會的用戶可以使用他們認爲更方便的任何一種。顯然,我將不得不將它們分成兩個非常獨立的命名空間,以避免類命名衝突,但是我認爲應該有一個Company.Tech.Database.DBContext命名空間和Company.Tech.Database.ObjectContext。
有誰認爲這是一個壞主意?好主意?我的理解是,雖然DbContext比較新,但它不一定比ObjectContext「更好」,它只是提供了一個可能被認爲更簡單但不依賴於用例的不同API。在這種情況下,不會提供這兩種API是好事嗎?
公平的評論。我想,我的問題措辭不是特別好。我更感興趣的是知道我是否會通過做這種事情來違反任何最佳做法。 –
@dark_perfect,通常不會,你違反的唯一的做法是提供兩種不同的API,正如我所說的那樣,導致更多的維護和迷惑用戶,他們會想知道什麼時候應該使用什麼?我不知道其他副作用。 –