［概述］
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和Repeater中，我们会看到它们的性能将优于DataGrid。
