用一個數據庫調用加載業務對象層次結構

Question

我想知道填充業務對象層次結構（父/子/孫結構）的最佳實踐來自單個數據庫調用。

我能想到的一對夫婦的方式來完成它關閉我的頭頂部，如：

左加入所有的關係，在我的SQL語句，然後使用循環和邏輯，以填補業務對象

或

使用幾種選擇語句和1周的DataReader並使用其NextResult（）方法來遍歷每個結果集，並填寫相應的BO的

只是想知道這種情況的最佳實踐是什麼

我使用DAAB和C＃我DAL

謝謝！

Answer 1

沒有通用食譜。它取決於數據庫模式，數據庫大小和應用程序在典型場景中讀取的記錄數。您這裏有兩個過程：從數據庫

• 獲取數據
• 填充業務對象

獲取數據從數據庫比在內存中創建對象要慢幾個數量級。最好的方法是構建用於最快數據訪問的選擇語句。

查詢可以通過三種方式來構建：

• ，其獲取在單個執行一切一個大的查詢 - 你會得到最複雜的SQL語句，可能是最快的執行（取決於DB模式）
• 主/細節方法 - 簡單的查詢。大量的流量到數據庫。只有當你取得少量的記錄時，這纔是可以接受的，否則它是非常慢的。
• 混合：每個層次的一個查詢。如果前兩種方法要放慢，請考慮採用這種方法。這種方法需要更復雜的邏輯來填充業務對象。

您應該決定哪種解決方案可以接受。一些需要考慮的要點：

• 哪個SQL更容易創建和維護 - 一個大的讀取單個讀取或幾個更小的一切。
• 當你在前面的角度選擇，你應該測量性能並作出最終決定

Answer 2

DataReader NextResult是最好的，因爲通過管道的數據量不會像聯接方法那樣快速增長。

Answer 3

我曾經使用多個返回的數據集，但是開銷，以及不斷變化的API，最終讓我返回到僅僅使用連接將它全部返回到一個大塊。

我一直關注結果集的大小，但在我遇到的任何應用程序的上下文中，這不是問題。總體而言，我並沒有後悔，但是YMMV。

如果父級別選擇子句涉及子級別選擇規則，則多個結果集可能特別松鼠。

這種方式處理所有情況;在某些情況下，將它分開有時會起作用，但最終會需要單個集合的查詢;只有一種模式是很好的 - 尤其是如果你有時陷於從一個到另一個的重構。

最後，最終數據庫的命中次數會減少，事務管理更簡單。

Answer 4

你有沒有考慮使用OR映射如NHibernate的？急切的加載可以完成你在一次調用數據庫時所要求的內容。

如果一個OR映射器不是一個選擇，那麼我會把我的投票放在datareader.NextResultSet的後面。

Answer 5

如果所有行從同一個表（或者看起來是），那麼你可以把數據拉成一個數據集一元關係和ADO.NET將連接層次爲你