Linq-to-SQL：多少個數據上下文？

我有一個具有> 300個表的SQL Server 2008數據庫。我必須設計的應用程序是Windows Forms應用程序，.NET 3.5，C＃。Linq-to-SQL：多少個數據上下文？

哪個是使用Linq-to-SQL最好的方法？

我打算爲每個業務實體制作一個數據上下文。

有什麼問題嗎？

我需要知道這種使用Linq-to-SQL的方式是否有缺點，或者可能會產生性能問題？

謝謝。

2010-05-29 sh00

http://www.west-wind.com/weblog/posts/246222.aspx – Gregoire 2010-05-29 14:30:42

對於每個數據庫，通常應該有一個單一的DBML文件（=數據上下文）。您當然不應該爲每個業務實體創建DataContext，因爲這樣做會使您失去LINQ to SQL的大部分有用功能，如內存事務（工作單元），延遲加載以及對多個實體執行LINQ查詢。

你有一個很大的模型（+300表），這意味着很多的實體。除了LINQ to SQL設計器之外，很多實體並不是一個大問題。使用這種大型模型的設計師可能會很煩人。這可能是在多個子域中分割域的原因（每個子域都有一個DBML文件），但當然不是每個實體都有一個。但是請記住，您在域的邊界處丟失了L2S功能。

在過去，我建議一個團隊將5個DBML文件中的+150實體域分割開來，將它們合併到一個DBML中。編輯模型的痛苦加劇了，但使用多個DataContext的痛苦消失了，這爲他們大大降低了整體疼痛。

2010-05-29 15:54:58 Steven

謝謝。請問，「編輯模型的痛苦」究竟是什麼意思？我認爲將子域中的大數據模型拆分可以解決一些性能問題。您是否具有在需要100多個併發用戶的勝利表單/ SQL Server數據庫中使用大數據模型/單個DBML文件的經驗？謝謝。 – sh00 2010-05-30 08:24:11

您創建的數據上下文類的數量對性能無任何影響。 – 2010-05-30 11:45:54

我同意本。我無法想象有多個DBML對性能有任何影響。請解釋你爲什麼這麼想。 – Steven 2010-05-30 14:09:33

爲每個業務實體創建數據上下文毫無意義，每個數據庫只需要一個數據上下文。

2010-05-29 14:35:50

好吧，這取決於有多少用戶同時使用您的數據庫，而不是有多少表。所以它關於典型的數據庫問題：連接數，鎖定和其他東西。

2010-05-29 14:36:32 Voice

我不認爲他在討論實例化DataContext，而是爲每個實體定義一個DBML文件。 – Steven 2010-05-29 15:56:27

是的，爲每個實體定義一個DMBL文件。謝謝。 – sh00 2010-05-30 08:15:00

我現在使用1作爲整個數據庫，但有更多的合法用途。例如，我在安裝連接到遠程數據庫的站點時運行腳本，並將數據導入並轉換爲新的部署格式。該過程使用一些臨時表。

通過將臨時表放入單獨的上下文中，一旦部署了網站，我可以簡單地刪除這些上下文和代碼，因爲它們是獨立的實體。

2011-04-15 10:44:13

回答