很早就想测试一下DataSet, DataReader的性能差别了
到了.Net 2.0时代，又多了一个泛类型集合绑定，于是我做了以下实验
前言：
测试代码未必标准，但是起码可以说明一些问题
主要使用重复绑定数据集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作为数据源了。
