有什么理由不使用嵌套的 EF 實體上下文嗎？

Question

using (var context = new FirstEntities())
{
   using (var context1 = new SecondEntities())
   {
   }
}

這行得通，但由於某種原因“感覺不對”......有誰知道不使用實體框架嵌套 using 語句的任何正當理由？

編輯：如果存在這種類型的嵌套可能導致異常或數據庫錯誤的情況，而不是從體系結構的角度來看是否可取，我的問題更多。

Answer 1

通過嵌套數據上下文，您將同時使用兩個數據庫連接。 最好從一個上下文中獲取所需的數據，關閉它並打開下一個上下文，然后從該上下文中獲取所需的數據。

這可能意味着更多的工作，因為您必須更好地規划代碼，但這也意味着應用程序可以更好地擴展。

Answer 2

如果您使用 SQL 服務器，事務中的嵌套上下文（使用獨立的數據庫連接）將升級為分布式事務，並且需要安裝和運行 MSDTC 服務，如果您連接到單個數據庫，這是不必要的復雜化。 這是一個很大的痛苦。 如果您可以管理您的上下文，使它們共享一個連接，您就可以避免這種非常不必要和不受歡迎的要求。

嵌套上下文的一個問題是 Entity Framework 不夠智能，無法知道連接是否指向同一個數據庫。 如果它們是不同的數據庫，那么您需要分布式事務協調器服務來維護數據庫之間數據的完整性。 如果連接到同一個數據庫，您就會被 DTC 行為搞砸了。

對於 SQL Server 2008 及更高版本，如果您沒有同時打開同一個數據庫的多個連接，DTC 行為將能夠檢測到這一點並讓工作按預期繼續進行。 例如，您可以按順序打開和關閉它們，而不是嵌套上下文：打開一個，做一些工作，關閉它，打開另一個，做更多的工作，關閉它，然后繼續不受 DTC 的干擾。

另一種解決方案是管理一個底層數據庫連接，以便它由嵌套上下文共享。 理論上，沒有多個連接，DTC 不會參與。 這是我正在研究的解決方案，但實體框架的體系結構使其實施起來有點困難。

有關連接管理器的信息，因此您不會打開相同的連接，可以在這個關於多個連接的答案中找到。