並行化L2S實體檢索

Question

假設與SQL Server和一個DBML一個典型的域實體接近/ L2S DAL與最重要的是一個邏輯層：

在的情況下的延遲加載是不是一種選擇，我已經在結算約定，其中獲取實體列表並不會獲得每個項目的子實體（不加載），但是獲取單個實體（急切加載）。

由於獲得單個實體也會得到孩子，它會導致一個級聯效應，其中每個孩子也會得到它的孩子。這聽起來很糟糕，但只要模型不太深，我通常不會看到超過易用性好處的性能問題。

因此，如果我想要得到一個列表，其中每個項目都與兒童充分水合，我結合了GetList和GetItem方法。所以我會得到一個列表，然後循環通過它獲取每個項目的完整級聯。即使這在我所從事的許多項目中都可以接受 - 但我最近遇到了需要更高效的更大型號和/或更多數據的情況。

我發現分割循環並在多個線程上執行它會產生出色的結果。在我的第一個實驗中，從一個特定項目中選出50個項目，我做了10個項目的5個線程，每個項目的時間都提高了3倍。

當然，里程會因項目而異，但其他條件相同時，這顯然是一個很大的機會。但是，在我進一步討論之前，我想知道其他人已經完成了哪些工作已經完成了。並行化這種類型的東西有什麼好方法？

Answer 1

通常，創建一個返回一組記錄的單個數據庫調用會更快。

此記錄集可以「保溼」頂層對象，然後另一個記錄集可以加載子對象。我不確定你的情況如何不允許延遲加載，但這種方法本質上是延遲加載，並且肯定會比每次對數據庫進行多次調用都會返回單個記錄的速度更快。

您可以對數據庫進行異步調用，以便多個查詢並行運行。如果將此與模型的每個「層」的第一個策略結合起來，並根據多記錄返回集寫出更復雜的水合函數，您應該會看到數據庫處理併發連接的效果非常好（這就是您看到的原因使用多個線程的性能增益）。

但是你不需要明確地創建線程 - 檢查出一個SqlCommand的asynchronous methods of。