数据源的选择：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.ltesting.net