数据源的选择：DataSet 与DataReader及泛类型集合的性能测试

第第页数据源的选择：DataSet与DataReader及泛类型集合的性能测试数据源的选择：DataSet与DataReader及泛类型集合的性能测试

发表于：2023-03-18来源：：点击数：标签：性能测试DataReaderDataSet数据源dataset

很早就想测试一下DataSet,DataReader的性能差别了到了.Net2.0时代，又多了一个泛类型集合绑定，于是我做了以下实验前言：测试代码未必标准，但是起码可以说明一些问题主要使用重复绑定数据集10000次（全部在服务端进行），绑定全部使用GridView的绑

很早就想测试一下DataSet,DataReader的性能差别了

到了.Net2.0时代，又多了一个泛类型集合绑定，于是我做了以下实验

前言：

测试代码未必标准，但是起码可以说明一些问题

主要使用重复绑定数据集10000次（全部在服务端进行），绑定全部使用GridView的绑定列

测试条件：

控件：GridView

字段：ID,NAME

数目15条

循环次数10000

测试次数3次软件:VS2023,SQLServer2023,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语句中先排好字段的顺序，比如SELECTID,NAME,TIEMFROMTABLE这样就解决了字段乱序的问题，如果服务器字段名更变了只需要修改SQL语句就好了。

那么表现层呢？表现层因为使用的是业务原型与泛类型集合，所以实现了与数据库字段的弱依赖，你只需要指定好原型的属性进行绑定就好了，操作方式和绑定DataSet的做法大概一致。

这样一来，除了添加了新字段，所有的改变都可以只通过修改SQL语句就可以全部更新。非常方便，而且效率更高。有人会问，使用DataSet同样可以实现弱依赖，只需使用列名编号DataTable.Rows[0][0]就可以了。的确，这样同样可以，但是会不会发现，比起Model.ID，DataTable