數據源的選擇：DataSet 與DataReader及泛類型集合的性能測試

　　前言：
        測試代碼未必標準，但是起碼可以說明一些問題
        主要使用重復綁定數據集10000次（全部在服務端進行），綁定全部使用GridView的綁定列
  
   測試條件：

　　控件：GridView
   字段：ID, NAME
   數目  15條
   循環次數 10000
   測試次數 3次    軟件:VS2005,SQLServer2005,WindowXP
   測試結果：
    DataSet: 9.6, 8.9, 8.75 = 9.08秒
        DataReader:6.5, 6.25,5.8 = 6.18秒泛類型集合: 7, 7.1,6.8 = 6.97秒總結     如果以DataSet的速度為標準，那么DataReader的速度提高了47%,泛類型數據集速度提高了30%,差距是隨著記錄集數量還有字段數量遞增的。

        從結果來看，雖然3次的時間不夠準確，但是足夠描述大概情況了，DataSet這種東西個人認為，除非有必要比如需要非連接更新，排序等等。一般沒必要使用.DataReader局限性太大而且靈活性不夠，個人認為綁定一些簡單控件比如DropDownList或ListBox差不多。當然它的主要用途還是用于后臺讀取數據并進行操作。            

        泛類型數據集，這個我是看了PetShop4.0后才學的。感覺配合DataReader以及業務原型（Model）一起使用足以替換DataSet。而且實際擴展和靈活性在某些方面甚至超過DataSet。
        我們使用DataReader的時候最怕數據庫位置變了（雖然不大可能），當然DataReader也可以根據列名獲取值，但是效率太低了，而且雖然解決了位置問題，但是無法解決字段名更改（這個比改位置的幾率還大） 我的解決方案是，在SQL語句中先排好字段的順序，比如SELECT ID,NAME,TIEM FROM TABLE這樣就解決了字段亂序的問題，如果服務器字段名更變了只需要修改SQL語句就好了。
        那么表現層呢？表現層因為使用的是業務原型與泛類型集合，所以實現了與數據庫字段的弱依賴，你只需要指定好原型的屬性進行綁定就好了，操作方式和綁定DataSet的做法大概一致。
        這樣一來，除了添加了新字段，所有的改變都可以只通過修改SQL語句就可以全部更新。非常方便，而且效率更高。有人會問，使用DataSet同樣可以實現弱依賴，只需使用列名編號 DataTable.Rows[0][0]就可以了。的確，這樣同樣可以，但是會不會發現，比起Model.ID ，DataTable.Rows[0[0]已經喪失了可讀性。所以對于現在的開發，除非有特殊需要，不然已經不需要使用DataSet作為數據源了。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: dataset 類型 數據源 性能測試 DataReader DataSet