在 ASPNET 页面中的控件若要展示数据库的数据或要写入数据库时我们可从 VS 的「工具箱」中点选 DataSource 控件用鼠标拖曳轻松地建立数据库联机但在 SqlDataSource 控件中预设使用的联机方式为具有「离线存取」功能的 DataSet 对象但就如章老师讲的不需要进行「排序筛选与分页」时根本没必要浪费内存反而还牺牲了一些程序性能 (performance)
因此若您的 ASPNET 页面使用了 SqlDataSource 作为控件的数据来源应视需求再手动调整 DataSourceMode 属性若您的 SqlDataSource 只是当作 LabelDropDownListListBox…等控件的数据绑定纯粹用来「显示」数据应如下图 所示在 VS 中在 SqlDataSource 的「属性」窗口中将 DataSourceMode 属性改为「DataReader」(预设为 DataSet)此举不但可提升程序存取速度亦可节省 server 上因 DataSet 造成非必要的内存消耗但若您的 SqlDataSource是用来当作 GridView 控件的数据来源且 GridView 需要分页排序筛选 (非指 TSQL 语句的 WHERE 或 JOINON而是指 DataSet 中的 DataTable 对象RowFilter 属性对已从数据库中捞取出来的数据再进行筛选) 这些功能即不用再手动调整 DataSourceMode 属性直接使用默认的 DataSet 即可
图 将 SqlDataSource 的 DataSourceMode 属性从默认的 DataSet 改成 DataReader
在 ADONET 中DataReader 可「单向 (顺向)只读」地读取数据库中的数据优点是读取速度快不须耗用 server 额外的内存DataSet 则是一种可让使用者「离线」存取数据的模式数据都会暂存至内存中有如可离线操作的数据库 (大家可以先猜看看是存在 clientside 还是 serverside 的内存)
DataSet 是从 ADONET x 开始微软即大力推广的「离线数据库存取模式」是为了改善早年 ADO 必须持续保持联机但在有大量用户同时上线时常造成 web 应用程序运作性能上的致命伤如今透过 ADONET + DataSet 的离线模式当程序透过 ADONET 取得数据之后会立即和数据库断线以释放资源但使用者仍可透过应用程序去存取内存中的数据库 (DataSet)并在必要的时候 (例如要把修改过的数据回写到数据库)才再重新建立联机回写然后再断线这样的运作方式能有效地节省数据库联机资源改善过去 ASP 网站为人垢病遇到大量使用者同时存取时性能不彰的缺点
「DataSet 离线机制」若用来开发同时间有大量用户存取的网站时也可减少与 server 往返沟通的次数降低网络的流量而「DataReader 实时联机机制」在一般情况下的执行性能反而较好因为 DataReader 在「读取」数据 (SQL SELECT) 的速度上一定会比 DataSet 快
至于 ADONET 的离线机制其 DataSet 对象到底存储在何处呢？就一些前辈们的使用经验而言如果是一个 Windows Form 程序其所建立的 DataSet 对象会储存在客户端的计算机内存中它与后端 server 的数据来源是完全中断连接的但如果是一个 Web Form 的 ASPNET 网页则所建立的 DataSet 对象会储存在 IIS server 的内存中
此外在 ADONET 中DataTable 已可单独存在不必再依附于 DataSet 中因此您也可视情况以 DataTable 替代 DataSet 来撷取操控数据如此亦可耗用较少的系统资源
虽然根据官方的说法DataReader 的特性为只读不允许使用者修改数据库里的数据但根据版工自行撰写的简单范例测试用 DataReader 做绑定的 TextBox使用者所输入的数据仍可再写入 SQL Server 中关于这点根据台湾网络上其它人的看法DataSourceMode 指的应该只是 SelectCommand (亦即以 SELECT 撷取数据的 SQL statement) 取回数据时所使用的一种「Mode」而已和 SqlDataSource 的其它指令无关其它指令使用的 SqlConnection 和 SqlCommand 是另外打开的应该与 SelectCommand 无关有兴趣测试的网友可由本帖下方下载此一测试示例示例中并另外展示如何用 Validator (验证控件) 去验证 DropDownList 控件要求用户至少要在 DropDownList 里选择一项才可按下按钮将 Form 数据 submit
