[摘要]［DataGrid控件］ 在三种控件当中，DataGrid是迄今为止功能最为丰富的，但也是最不灵活的控件。这种在输出HTML时不够灵活的特点是因为它最初就是被设计成以表格的形式输出数据。每一条记录输出时会建立一对<tr>标签，而每个字段的值输出时则建立一对<td>标签。...
［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的设定是为了有一个耗时的处理过程，来看一下它对于每秒种的页面请求有什么样的影响。测试结果见图1。
图1：对DataGrid的每秒请求次数
在下面我们要讨论并测试的DataList和Repeater中，我们会看到它们的性能将优于DataGrid。
……