EF4 DAL設計和ObjectContext：與同事的爭論

Question

我與一位高級.NET開發人員一起工作。在過去的6個多月裏，我們已經進行了許多建設性的爭論，通常我會在大部分討論中承認失敗。我已經與他一起學習了堆棧。但是，我們目前有一個設計問題存在分歧，我想提出一些意見/建議，因爲他沒有設法讓我相信他的立場，我會堅持我的槍支，直到有人能夠給我證據證明我我錯了。

我們使用實體框架4.0，我們在不同的模型中使用兩個持久感知和自我跟蹤的實體。我們開始使用自我跟蹤的實體來跟蹤對通過WCF線序列化/反序列化的實體圖的更改以發送到我們的Silverlight應用程序。它非常有效。我們也開始使用自我跟蹤實體來處理我們沒有通過WCF採用的模型，但是許多模型仍然是持續感知的實體/模型。

我的同事認爲Entity Frameworks ObjectContext應該儘可能在最短的時間內保持。他堅持認爲，只有在查詢所需的時間長度和持續時間所需的時間長度之間。任何與實體做的業務工作都應該被分離。對於我們擁有的每個實體模型，我們有一個查詢類和一個持久類，它們都是IDisposable，並且在實例範圍內具有ObjectContext，並且在方法中具有查詢/持久性邏輯。我們在業務邏輯中使用這些查詢/持久化類，而不是直接在業務邏輯中使用ObjectContext。當構造這些類實例時，ObjectContext以及Disposed時，ObjectContext處置也是如此。這些類就像我們LINQ操作的包裝器，將業務邏輯與EF分開，並協助LINQ查詢重用。

現在首先考慮非自跟蹤實體：

我明白爲什麼他要這樣的願望不具有長期運行ObjectContext的，但我的問題是，他總是想甚至瑣碎的業務邏輯從被分離ObjectContext和在我們的設計下我們有一個單獨的查詢和持久性上下文的事實意味着沒有ObjectContext狀態跟蹤我們的業務邏輯中使用的實體。對於非自我跟蹤的實體，這意味着如果我們修改我們的業務邏輯中的實體，我們還必須在持續之前手動設置實體的修改狀態。當持續多個變化的複雜圖形時，這是一個真正的痛苦。另外我懷疑我們可以手動完成，EF也會自動完成。

對於我們的自我跟蹤實體，這種情況是相同的，因爲跟蹤只在圖形被反序列化時打開，所以當在執行查詢的服務中工作時，與上下文分離，仍然沒有跟蹤自我跟蹤的實體。

我的問題是，實體框架使用的最佳實踐是什麼？應該如何設計實體框架DAL？ ObjectContext需要多長時間？業務邏輯是否應始終與ObjectContext分離？如果是這樣的話，我們如何在從ObjectContext脫離工作時進行狀態跟蹤？我正在考慮的一個選擇是將我們的所有實體轉換爲自我跟蹤實體，並使用一些圖遍歷代碼來遍歷查詢圖並打開圖中所有實體的跟蹤，以便自我跟蹤即使在工作服務端（基本上模仿自我跟蹤實體圖解序列化時會發生什麼）...

我不是建議我們長時間保持ObjectContext，而是在查詢和持久性之間工作分離，並失去ObjectContext狀態跟蹤對我的好處似乎很愚蠢......我們失去了EntityFramework的一大好處...

對不起，對於很長一篇文章...任何幫助讚賞。

Answer 1

Microsoft建議ObjectContext應該是短暫的，而且我的經驗讓我相信ObjectContext的生命週期應該與Web請求/用戶操作的持續時間理想相關。

我犯了一個錯誤，試圖在桌面應用程序中使用全局的，長期存在的ObjectContext，這是一場徹頭徹尾的災難。如果你要實現諸如緩存，/重做編輯語義等，那麼你應該考慮使用ViewModel類的設計，這些類與底層數據實體明顯不同。使用EntityFramework來幫助您構建模型對象圖，然後從中構建ViewModel。當您想要保存更改時，請允許ViewModel存儲庫重新連接到基礎實體，更改其屬性並保存更改。這樣可以實現更「靈活」，靈活，ORM獨立，單元測試友好的設計。

在更改跟蹤方面，儘量不要將其視爲UI的便宜的「用戶自定義更改」機制，而應將其視爲用於跟蹤哪些最近創建的實體需要考慮的昂貴機制當保存更改時。