DataSet表示一个数据集,是数据在内存中的缓存。 可以包括多个表
DataSet 连接数据库时是非面向连接的。把表全部读到Sql中的缓冲池,并断开于数据库的连接
DataReader 连接数据库时是面向连接的。读表时,只能向前读取,读完数据后有用户决定是否断开连接。
分布式系统的数据可能会用dataset做数据载体,因为dataset是保存数据的数据结构,而DataReader不承担保存数据的责任,它只负责从数据源读取数据到本地而已,它不是数据结构,而是网络通讯组件的高层封装。 DataAdapter也只是使用DataReader从数据源读取数据并Add到dataset保存起来而已。假如我们单独使用DataReader也可以把数据写入到业务类或者dataset里。那只是根据业务需要而选择不同的数据载体而已。实际上我们从数据库获得数据都会通过DataReader,只不过DataAdapter把这一切都封装起来了
DataSet 和 DataReader对象有什么区别?
DataSet可以离线处理,前后滚动.DataReader不能离线处理,且是只读的向前的,不过速度明显会很快;
DataSet可以存储数据库各种对象的,比如表触发器等,而DataReader只能存储游标记录
DataSet可以更新回原来的数据库,DataReader不行;
DataSet可以FORWORD PREVIUS,而DataReader只能FW;
DataReader类似一个只能向前的游标记录集
DataSet叫数据集!是ADO.net相对与ADO实现断开式数据库连接性的主要体现!DateReader是一个客户端的只向前游标,两者的应用领域不同!读取数据后!如果要进行比较频繁的改动,可以使用DataSet,并且DataSet也支持串行化,可与xslt结合!进行web开发!
DataReader则偏向于快速读取数据!针对数据量比较大的数据可能应用的更加频繁点!
ADO.NET提供以下两个对象,用于检索关系数据并将其存储在内存中:DataSet和DataReader。DataSet提供一个内存中数据的关系表示形式,一整套包括一些表在内的数据(这些表包含数据、对数据进行排序并约束数据),以及表之间的关系。DataReader提供一个来自数据库的快速、仅向前、只读数据流。
当使用DataSet时,经常会利用DataAdapter(也可能是CommandBuilder)与数据源进行交互。当使用DataSet时,也可以利用DataView对DataSet中的数据应用排序和筛选。也可以从DataSet继承,创建强类型DataSet,用于将表、行和列作为强类型对象属性公开。
下列主题包括的信息涉及:使用DataSet或DataReader的最佳时机、如何优化访问它们所包含数据、以及如何优化使用DataAdapter(包括CommandBuilder)和DataView的技巧。
DataSet与DataReader
当设计应用程序时,要考虑应用程序所需功能的等级,以确定使用DataSet或者是DataReader。
要通过应用程序执行以下操作,就要使用DataSet:
r 在结果的多个离散表之间进行导航。
r 操作来自多个数据源(例如,来自多个数据库、一个XML文件和一个电子表格的混合数据)的数据。
r 在各层之间交换数据或使用XML Web服务。与DataReader不同的是,DataSet能传递给远程客户端。
r 重用同样的记录集合,以便通过缓存获得性能改善(例如排序、搜索或筛选数据)。
r 每条记录都需要执行大量处理。对使用DataReader返回的每一行进行扩展处理会延长服务于DataReader的连接的必要时间,这影响了性能。
r 使用XML操作对数据进行操作,例如可扩展样式表语言转换(XSLT转换)或XPath查询。
对于下列情况,要在应用程序中使用DataReader:
r 不需要缓存数据。
r 要处理的结果集太大,内存中放不下。
r 一旦需要以仅向前、只读方式快速访问数据。
注填充DataSet时,DataAdapter使用DataReader。因此,使用DataAdapter取代DataSet提升的性能表现为节省了DataSet占用内存和填充DataSet需要的循环。一般来说,此性能提升只是象征性的,因此,设计决策应以所需功能为基础。
经常听到有人问这个问题:“在ASP.NET Web应用程序中我应该用DataReader类还是DataSet类呢?”在很多文章以及新闻组的贴子中我经常看到这样的误解,即认为DataReader(SqlDataReader或OleDbDataReader的缩写)比DataSet好。有时候我也会看到相反的说法。事实上,Microsoft创建了这两个数据存取类是因为它们都是我们所需要的。每个类都有其优点和不足,你可以根据应用环境来选择用哪一个。
本文就两者的选择问题做了很清楚的讲述,可以让你在运用ASP.NET时,在选择DataReader类或DataSet类的方面得到一些指南。在基于客户端的Windows Form应用程序环境下,这些规则可能会改变。我在做这些讲述时,假设你已经用过DataReader和DataSet类了,并对它们很熟悉。
运用DataReader类
下面就是运用DataReader类的理想条件:你读取的数据必须是新的,所以在每次需要数据的时候,你都必须从数据库读取。创建一个DataReader类不会消耗很多内存,不过随着负荷的增加,DataSet上的性能也会很快地提高(参考资源中Visual Studio Magazine中的文章)。
你对每行数据的需求很简单。该情况的最好的例子就是简单地将DataReader绑定到一个Web控件,如DataGrid或DropDownList。
你只需要从数据库中以只向前的(forward-only) 、只读的形式来存取XML数据。在这种情况下,你可以用SQLCommand对象的ExcecuteXmlReader()方法来得到一个XmlReader类(相当于XML版的DataReader)。这就需要一个运用FOR XML子句的SQL Server查询,或者一个包含有效XML的ntext字段。
你计划对数据库进行几个重复的调用,来读取一小块信息。在这种情况下,我们前面提到过的性能数据会有更大的提高。
的确,使DataSet类更强大的许多功能只适用于基于客户端的Windows Form应用程序,比如在多个表之间建立关系的功能。在很多情况下,DataSet类都比DataReader类更有优势,而且在有些情况下,你根本就不能用DataReader类。
运用DataSet类
在下面的情况,你应该考虑运用DataSet类: 你构建了一个Web service,它运用的数据是你作为返回值读取的数据。因为DataReader类必须保持到数据库的连接,所以它们不能被序列化到XML中,也不能被发送给一个Web service的调用者。
你需要排序或筛选数据。在运用一个DataView对象(呈现为DataTable类的DefaultView属性,它包含一个DataSet类)来排序或筛选数据前,我们先试着用SQL查询(如WHERE和ORDER BY语句)来实现这些功能,并运用更轻量级、更快的DataReader类。然而,有时侯用这种方法是不行的,或者当你需要多次地对数据进行排序或筛选时就不能用DataReader。
针对同一请求,你需要多次遍历数据。你只能在DataReader中循环一次。如果你想将多个ServerControl类绑定到同一个数据集,那么选择DataSet就更好。DataReader类不能被绑定到多个ServerControl类,因为它是只向前读取的。在这种情况下,如果要使用DataReader,必须从数据库读取两次数据。
你需要存储数据,而后续的页面请求可能会用到的这些数据。如果数据只被请求它的专门的人使用,你可以将DataSet类保存在一个Session变量中。如果数据可以被任何人访问,那么你可以将它保存在一个Application变量中,或保存在Cache中(我建议使用后一种方法,因为它支持时间期限和回调(callback))。因为DataReader类必须一直打开对数据库的连接,而且它一次只能保存一行数据,所以它们不能在跨页面请求中被保存。
你需要对一个结果集的每个元素实现特殊的、耗时的功能。例如,如果你从一个数据库读取一列邮政编码,并想通过调用一个Web service来得到每个地区的详细的天气状况信息,那么选择DataSet就会更好。这是因为,当你在用DataReader类时,在关闭DataReader类前,与数据库的连接不会被释放回连接池。在数千页面请求之间潜在的一个很小的延时都会造成Web应用程序的很高的访问量,从而就会消耗完可用的连接。相反,DataSet可以在前端读取所有的数据,并可以马上关闭与数据库的连接,将它返回到连接池,因此其它的页面请求就可以用这个连接了。
你需要在一个两维范例中加载并处理XML数据。DataSet类对于XML很有用,因为你可以将DataView用于XML,对根本的数据进行排序和筛选,就同处理一个数据库结果集一样。然而,需要注意的是在System.Xml名字空间中有很多类,你可以将它们用于更复杂的XML操作。
你的数据源不是一个数据库。虽然OleDbDataReader可以用于任何OLEDB数据提供者(可能指向一个数据库,也可能不指向一个数据库),但DataSet对象可以从一个XML文件直接加载数据,并动态地解释它的schema。DataSet类也可以将XML数据写回一个数据流或一个文件。
从上面的讲述我们就可以看到,DataSet类比DataReader类有更多的功能,这就可以让你在更多的情况下运用它们。但这并不意味着你总是在用DataSet类。你需要在ASP.NET中完成的相当大一部分的任务都属于DataReader的范畴。
尽管如此,毫无疑问,从重要程度或复杂程度的角度来说,DataSet类在很多ASP.NET Web应用程序中都起着很重要的作用。你可以通过明智的缓存来最小化数据库往返,从而降低DataSet类的“性能损害”。DataReader和DataSet都是一个成功的ASP.NET Web应用程序的重要的部件。重要的是,我们需要了解何时、在哪里可以最好的使用它们。
来源:http://www.cnblogs.com/puke/archive/2007/07/24/829290.html
WEB开发自从有了基于脚本的WEB编程技术(如ASP)以来,经历了一个漫长的过程。通过使用微软的asp.net技术,传统的ASP中大量的、单调乏味的、重复性的编程工作成为了历史。例如,象大多数ASP程序员所知的,在ASP中显示数据库内容所需要的过程:
建立数据库连接
用SQL查询装载ADO数据集
显示所需要的任何HTML代码
遍历数据集中的记录
输出记录字段值及相关的HTML
移向下一条记录
循环
显示所需要的HTML代码
又如,为了在表格中显示记录集的内容,我们需要输出一个<table>标签,然后开始循环。在循环中,每输出一条记录,需要先输出一个<tr>标签以及若干对<td>标签和</tr>标签。最后,以一个</table>标签结尾。
在传统的ASP中使用的这种方法有一个主要的缺点:HTML代码与ASP源代码不得不纠缠在一起。对于那些也许并不理解程序设计的页面设计者或图形艺术家来说,想要更改HTML内容无疑是一场灾难。另外,代码的产生量也是惊人的,因为我们不仅需要从数据库中取得数据,还需要使之可视化。
好在,ASP.Net提供了三个数据控件,使得原本在ASP中繁杂的工作变得简单。这三个控件属于数据Web控件,分别是DataGrid,DataList和Repeater。如果你对ASP.Net数据库编程有所了解的话,你至少应该有使用其中一种控件的经验。大多数情况下,我们从学习使用DataGrid开始,因为它的功能相对完整(数据显示、分页、编辑)并相对简单。然而,DataGrid并非总是正确的选择。
本文将分别论述每个数据控件不同于其它数据控件的特点,以及由此带来的优缺点。正因为每种数据控件都有其自身的缺陷,因此在程序设计中并不存在最完美的选择。你必须权衡三种控件的优缺点并决定哪一种更加适合你的程序。
为了帮助比较,在对每个控件进行论述时,我们会专注于三个特性:可用性(从页面访问者的角度)、开发时间和性能。我们首先描述一下这三种控件的共性,然后分别深入地讨论三种控件的特点,每种控件如何实现以及如何体现可用性、开发时间和性能。
[数据控件(Data Web Controls)的共同点]
在我们讨论三种控件各自特性之前,有必要先看一看它们之间的共同点。一般来说,从编程流程来看,最显著的共同点就是,这三种控件都是用来显示数据的。另一个共同点是需要一个数据绑定的代码来将数据与控件绑定。这个过程只需要两行代码:
dataWebControlID.DataSource = someDataSource
dataWebControlID.DataBind()
一般情况下,someDataSource对象是指数据控件的数据源属性,可以是DataSet,SqlDataReader,OleDbDataReader或一组数据(如数组、数组列表或其它的属于System.Collection名空间的类)。不过,任意实现IEnumerable接口的对象也可以被绑定在数据控件上。
DataBind()方法遍历一个特定的DataSource中的记录,并对其中的每条记录,建立一个条目并对应数据控件的Item集。数据控件中的每个条目将成为一个类的实例。这个类因数据控件的不同而有所区别。例如,DataGrid中的每个条目是DataGridItem类的一个实例,而Repeater中的条目则是RepeaterItem类的一个实例。
之所以使用不同的类来实例化不同数据控件的条目,是因为不同的数据控件将会使用不同的方式显示数据及相应的HTML代码。例如,DataGridItem类继承自TableRow类,也就是说,每个DataGridItem的实例或多或少地可以看成一个表格中的一行。这是因为DataGrid被设计成可以借助HTML中的<table>标签以表格的形式显示数据,因此每条记录就是一个表格行。而Repeater则被设计成可以自由定义数据输出的方式。所以,RepeaterItem并不继承自TableRow就不奇怪了。
另一个三种数据控件的相同点是每种控件都被允许使用模板来显示数据。DataList和Repeater控件必须使用模板来输出数据,而DataGrid则允许通过TemplateColumn而只使用模板来显示一列(在DataGrod单元中详细论述)。
另一个不是十分值得比较的地方是:DataGrid和DataList都是继承自WebControl类,而Repeater则是继承自Control类。WebControl类包含一些用于美化的属性,如:BackColor、ForeColor、CssClass、BorderStyle等等。这说明在使用DataGrid或DataList时,你可以设定这些属性来个性化输出。Repeater控件则不具有这些属性。我们会在Repeater单元讨论如何使用模板来美化Repeater的输出。
[DataGrid控件]
在三种控件当中,DataGrid是迄今为止功能最为丰富的,但也是最不灵活的控件。这种在输出HTML时不够灵活的特点是因为它最初就是被设计成以表格的形式输出数据。每一条记录输出时会建立一对<tr>标签,而每个字段的值输出时则建立一对<td>标签。
DataGrid含有几个属性可以提高其可用性。如,通过设置DataGrid的AllowSorting属性为true,并加入少量代码,DataGrid就具备了按不同字段排序的功能。此外,设定相关属性来实现分页以及单条记录编辑的功能更加增强了DataGrid的可用性。
除了在可用性方面的支持以外,DataGrid同时也相当节省开发时间。使用DataGrid在WEB页面上显示数据只需要两行代码。一行用来设定与DataGrid绑定的数据源(DataSource),另一条则用来执行绑定命令(DataBind())。当然,在Repeater中实现这样的功能并非不可能,只是,相比较使用DataGrid而言,你需要花费相当多的时间和精力来实现这些功能。
尽管DataGrid有这样那样令人印象深刻的优点,它的两个缺点也同样不能忽视。首先,如前所述,DataGrid在个性化输出数据方面功能有限。当然,你可以定制字体、颜色以及线条宽度等等,但它始终只能是HTML表格。
每个在DataGrid中的列都是DataGridColumn类的一个实例。有五种DataGrid列的形式:
·BoundColumn
·ButtonColumn
·EditColumn
·HyperLinkColumn
·TemplateColumn
每种类型都会以一种方式允许页面访问与DataGrid进行交互。例如,BoundColumn将DataSource的字段值显示为纯文本;而HyperLinkColumn则将之显示为一个超级链接。另外,开发者可以通过写一个继承自DataGridColumn的自定义类来定制DataGrid列的样式。
尽管DataGrid具有这么多的增强可用性的属性,却仍然显得死板而不够灵活。这是因为,不论什么样的属性,都需要对DataGrid所生成的表格进行相关的设置而生效。这无疑会使表格变得臃肿而失去灵活性。例如,DataGridColumn的设置会对表格的每一行的相应列生效。DataGrid的这种局限性阻碍了更有创意地显示数据。比如,你希望每五条记录被显示在一行,或根本不想要表格来显示数据,你将不得不放弃使用DataGrid。
DataGrid的第二个缺陷是它的性能。在三种数据控件中,DataGrid是相对性能最差的。由DataGrid所生成的ViewState将会相当庞大,特别是在DataGrid含有较多的行时。当然,你也可以关闭ViewState功能,但代价是你将不能使用排序、分页以及记录编辑等功能。
为了测量DataGrid的性能,我使用了微软的Web Application Stress Tool (WAST)。精确的测试条件设定以及测试用代码将会在本文的结尾给出。
WAST将会对WEB服务器发出对一个特定URL的请求。每个测试将会针对一个URL在一分钟之内连续不断地请求。WAST将会一个代表性能的数值,代表WEB服务器将会在一秒钟内执行ASP.Net页面多少次。
两个测试将显示一个仅仅显示数据的DataGrid。DataGrid将会显示Northwinds数据库中的Customers表的4个字段的内容(总计91条记录)。DataGrid的AutoGenerateColumns属性将会被设为True。第一个测试将DataGrid置于一个Form中,第二个则不置于Form中。将控件置于Form中而不指定其EnableViewState为False,则控件将会一直使用ViewState来维持其状态。对ViewState的设定是为了有一个耗时的处理过程,来看一下它对于每秒种的页面请求有什么样的影响。
[DataList控件]
如前所述,DataGrid使用表格来显示数据。你也许需要更进一步地控制数据的显示。例如,你想使数据在表格中显示,但不是每行只有一条记录,而是多条。又或者,你并不想使用表格来显示数据,而是只将它们显示在一系列<span>标签中。
DataList放弃了DataGrid中列表显示数据的概念,而是使用事先定义好的模板(Template)来定制显示。通过使用模板,可以同时使用HTML标签或数据绑定。这里的数据绑定的形式为:<%# … %>,用来显示数据源中给定条目的数据记录。如下的ItemTemplate将会显示数据源中CompanyName字段:
<asp:DataList runat="server" id="myDataList">
<ItemTemplate>
<%# DataBinder.eval_r(Container.DataItem, "CompanyName") %>
</ItemTemplate>
</asp:DataList>
通过修改上面的模板,我们可以使CompanyName字段显示为粗体字,而ContactName字段则以正常式样显示在CompanyName之下。
<asp:DataList runat="server" id="myDataList">
<ItemTemplate>
<b><%# DataBinder.eval_r(Container.DataItem, "CompanyName") %></b>
<br />
<%# DataBinder.eval_r(Container.DataItem, "ContactName") %>
</ItemTemplate>
</asp:DataList>
对于DataList数据源中的每一条记录,ItemTemplate会通过定义HTML标签来以相同的样式显示数据。ItemTemplate还支持其它其它6种模板:
·AlternatingItemTemplate
·EditItemTemplate
·FooterTemplate
·HeaderTemplate
·ItemTemplate
·SelectedItemTemplate
·SeparatorTemplate
默认情况下DataList会将记录显示在HTML表格中。然而,通过设定RepeatColumn属性,你可以设置在一行中显示多少条记录。更进一步,你甚至可以指定DatList的内容不显示在表格中,而是<span>标签中。这可以通过设定RepearLayout属性来实现。
通过模板、RepeatColumn和RepeatLayout属性,很明显DataList在定制数据输出样式方面较DataGrid更具灵活性,使得用户界面设计可以更加友好。当然,我们还需要进行功能性的对比,如分页、排序、记录编辑等等。
通过EditItemIndex模板和EditCommand,UpdateCommand以及CancelCommand事件,DataList将支持记录编辑的功能。不过,比较DataGrid而言,这需要耗费更多的开发时间来实现。这种开发时间上的不一致主要有两个原因:
·编辑/更新/删除按钮在DataGrid中可以通过设定EditCommandColumn来自动添加;而在DataList中则需要手动添加。
·DataGrid的BoundColumn列样式自动使用文本框控件来显示记录编辑界面。而在DataList中,你必须通过EditItemTemplate明确地指定使用什么样的编辑界面。
实现DataList中的分页、排序功能同记录编辑功能情况一样,并不算非常复杂。这些功能可以通过巧妙的编程加以实现,只是耗费一些开发时间。所以,如果需要用户对数据记录进行排序或编辑的话,使用DataGrid要比使用DataList方便得多。
DataList的性能要比DataGrid好一些,特别是当DataList被包含在Form当中时。图2显示了WAST对DataList的测试。
可以看出,在被Web Form包含的情况下,DataList的性能要明显好于DataGrid。
[Repeater控件]
Repeater控件是三种数据控件中在HTML输出方面最为灵活的控件。Repeater会按照你所要求的样式严格地输出数据记录。所以,如果你不想以表格方式或者简单的<span>输出数据,那么最好使用Repeater。
与DataList一样,Repeater使用模板来指定输出样式。Repeater支持如下五种模板:
·AlternatingItemTemplate
·FooterTemplate
·HeaderTemplate
·ItemTemplate
·SeparatorTemplate
HederTemplate和FooterTemplate指定在真正的记录输出之前或之后应处理的HTML内容。AlternatingItemTemplate和ItemTemplate则指定实际的每条输出记录的HTML样式。如,你需要绑定一个包含雇员信息的DataSet到一个Repeater,字段名为EmployeeName。如果你想在页面中不排序地显示这些记录,你可以使用如下的语句:
<asp:Repeater runat="server" id="rptEmployees">
<HeaderTemplate>
<ul>
</HeaderTemplate>
<ItemTemplate>
<li><%# DataBinder.eval_r(Container.DataItem, "EmployeeName") %></li>
</ItemTemplate>
<FooterTemplate>
</ul>
</FooterTemplate>
</asp:Repeater>
Repeater类不是继承自WebControl类的,这一点与DataGrid和DataList不同。所以,Repeater没有样式方面的属性可供设定。也就是说,如果你想格式化输出Repeater的数据记录,你必须使用HTML标签来设定样式。如,在一例中,如果我们想将雇员名字显示成粗体,我们必须在ItemTemplate设置相应的HTML标签:
<ItemTemplate>
<li><b><%# DataBinder.eval_r(Container.DataItem, "EmployeeName")%></b></li>
</ItemTemplate>
而如果使用DataGrid或DataList,我们只通过设定ItemStyle-Font-Bold属性为True即可实现。
Repeater在格式化设定上的欠缺,直接反映到开发时间的延长上来。对输出数据样式上的越多要求,就越会导致开发周期的延长。这些在模板中规定样式的HTML标签也越发得显得混乱,而且,在将来页面更改时会更加困难,特别是当一个新的开发人员接替工作时。而使用DataGrid或DataList你尽可以只设定样式属性,而不使用模板。而且,如果使用Visual Studio.Net或ASP.Net Web Matrix工作时,这些属性更可以被直接设定而无需编码。
因为Repeater开发时间的延长,其在内建功能(分页、排序及编辑)上的支持也显得不足。因此在可用性方面,Repeater有着明显的缺陷。当然,<b>如果</b>用户对于如何显示数据无所谓的话,这也算不了什么大问题。我之所以强调这个“如果”,是因为尽管用户有时在设计时并不要求能够分页、排序或编辑记录,但这样的要求往往会在开发后期,或在他们能看到显示出来的记录后产生。
Repeater唯一优于DataGrid和DataList的特点是它的性能,尤其明显优于DataGrid。而比DataList略高一点点。
[结论]
在ASP.Net页面上显示数据时,多数的程序员会选择他们所熟悉的控件来使用,特别是DataGrid。然而,这样盲目的选择在没有“最好的通用控件”的情况下是不明智的。在选择控件来显示数据前,不妨问自己几个问题来帮助决策:是否允许用户对记录排序?是不是记录需要显示在非表格的情况下?页面是否会被高频度地访问,因此应多考虑性能?
DataGrid提供了最多的功能,如允许访问者对记录编辑、排序或分页。同时它也是最容易使用的,甚至于简单到只需要将之添加到页面中而不必额外编写代码。不过这些易用性是以性能的损失为代价的。DataGrid在三种控件中是效率最低的,特别是在使用Web Form的情况下。
通过使用模板,DataList提供了比DataGrid更加优秀的界面效果。不过这需要以牺牲一定的开发时间为代价。为了添加排序、分页和编辑功能,程序员不得不花费比使用DataGrid更多的精力来进行编码,虽然它的性能要优于DataGrid。
最后,Repeater允许对数据记录作最大限度的HTML定制。通常,使用Repeater来显示数据记录比使用DataGrid和DataList要耗费更长的开发时间。另外,它不支持内建的编辑、排序和分页功能。所幸的是,Repeater在性能上要优于其它两种控件,特别是明显优于DataGrid。