DataContext是否可以靜態化？

在LINQ2SQL和Entity Framework中都有類似的DataContext對象，它是整個資料對應的載體和資料操作的入口。DataContext是一個標準的Unity of Work的實現，它可以保證在一個DataContext內容相關的多個資料操作，保持事務的原子性。DataContext還具有資料容器的性質，維護了所有操作資料的狀態，它會跟蹤您對所有檢索到的實體所做的更改，並且保留一個“標識緩衝”，該緩衝確保使用同一對象執行個體表示多次檢索到的實體。即使是LINQ2SQL和Entity Framework還有很多的不同，但是DataContext的行為都基本差不多。

DataContext承擔這麼重要的工作，很多人擔心它是一個很重的對象，建立和銷毀都需要消耗比較多的資源（比如映射關係的初始化等），因此尋思著是否可以對DataContext對象進行靜態化，讓整個程式只使用一個DataContext對象。希望通過這樣，來盡量減少頻繁建立和銷毀DataContext所帶來的效能損耗。可是事實確實如此嗎？來看看下面的幾點簡單的分析吧：

1. 在MSDN文檔中，對LINQ2SQL DataContext的描述中，有特別說明了一點：“DataContext 是輕量的，建立它不需要很大的開銷。典型的 LINQ to SQL 應用程式在方法範圍內建立 DataContext 執行個體，或將這些執行個體建立為生存期較短的類（這些類表示相關資料庫操作的邏輯集合）的成員。”也許是擔心很多人對DataContext的誤會，在MSDN中還特別說明了應該是在方法範圍內，或者是作為生存周期轉短的類的成員，以求盡量早的釋放和回收DataContext資源。
2. DataContext不是安全執行緒的對象，在MSDN中是這樣描述的：“此類型的任何公用 static（在 Visual Basic 中為 Shared） 成員都是安全執行緒的。但不保證所有執行個體成員都是安全執行緒的。”沒有安全執行緒的保證，會讓我們在多線程共用DataContext時，出現很多隨機的、意想不到的結果。比如，由於DataContext會緩衝所有的資料操作，此時我們一個線程的資料修改到一半，之後還有其它的資料需要被修改，但是它卻有可能被另一個線程在調用SaveChanges時被意外提交了。此類問題，經常都是隨機的，而且一般是在開發時不容易被發現的，只有當程式在高並發的環境下才會頻繁發生。
3. DataContext還具有資料容器的性質，所有從DataContext取出來的資料都被會它所跟蹤。它需要跟蹤這些實體物件的變化情況，以便在SaveChanges的時候，決定對實體物件施加相應的操作，是添加，修改（還包括修改的欄位），還是刪除。同時，它一般還具有“標識緩衝”的功能，它可以減少與資料庫的互動次數，保證使用者在同一個DataContext裡面多次檢索到同一行資料時以同一對象執行個體的表示。可以預見，如果DataContext靜態化的情況下，那麼對象容器裡緩衝的這些實體物件的釋放和回收時機得不到保證，甚至在整個程式周期內無法得到釋放，並且對象也無法得到及時的更新。

也許還有其它的可能，我並沒有考慮到。但是基於以上3點，我們就可以得到答案。DataContext是不應該被靜態化，或者是單例化的。然而很多時候，瞬時的DataContext也不能夠滿足需求，比如當我們需要從一個方法裡面返回出一個實體物件，而這個實體物件是用方法內部自定例化的DataContext對象取出的。一旦在方法外部，想要持久化實體物件的修改時，由於無法得到DataContext執行個體而無法儲存。此時，我們可能要頻繁的把DataContext作為方法參數進行不斷的傳遞，這樣也太麻煩了。因此，在實踐中，我們一般都會讓DataContext在當前請求上下文保持單例，讓DataContext一個請求上下文周期內單例既可以避免傳遞，還可以保證安全執行緒。

也有同事提出，讓讀用一個DataContext，寫用另一個DataContext，用讀寫分離的概念來使用DataContext。雖然沒有實踐過，但還是得注意安全執行緒與對象的回收時機問題。總之，使用DataContext的靜態化， 除非非常必要，否則在Web環境中這樣使用，肯定會帶來很多不必要的麻煩。