Analyzing the DataList
Recall that the DataGrid renders as an HTML <table>
, which each DataSource record as a table row (<tr>)
and each record field as a table column (<td>
). At times you might want more control over the presentation of data. For example, you might want to have the data displayed in an HTML <table>,
but rather than have one record per row, you might want to display five records per row. Alternatively, you might not want to have the data displayed in a <table>
tag at all, but rather have each element displayed in a <span>
tag.
The DataList abandons the “column” notion adopted by the DataGrid. Instead, the DataList’s display is defined via templates. With a template, the developer can specify both a mix of HTML syntax and databinding syntax. The HTML syntax is regular HTML markup; databinding syntax is delimited by the <%# and %>
tags, and is used to emit contents from the DataSource
record used in constructing a given DataList item. For example, the following ItemTemplate will display the DataSource
field CompanyName
:
<asp:DataList runat="server" id="myDataList">
  <ItemTemplate>
   <%# DataBinder.Eval(Container.DataItem, "CompanyName") %>
  </ItemTemplate>
</asp:DataList>
In addition to the databinding syntax, the template may contain HTML markup. By updating the above template, we can have it so that the CompanyName
field is displayed in a bold font, while the ContactName
field is displayed beneath the CompanyName
field in a non-bold font:
<asp:DataList runat="server" id="myDataList">
  <ItemTemplate>
   <b><%# DataBinder.Eval(Container.DataItem, "CompanyName") %></b>
   <br />
   <%# DataBinder.Eval(Container.DataItem, "ContactName") %>
  </ItemTemplate>
</asp:DataList>
For each record in the DataList’s DataSource, the ItemTemplate’s databinding syntax is evaluated. The output of the databinding syntax, in addition with the HTML markup, specifies the HTML that is rendered for the DataList item. Along with the ItemTemplate the DataList supports six other templates for a total of seven:
Note that the DataGrid’s TemplateColumn only supports four templates: ItemTemplate, HeaderTemplate, FooterTemplate and EditItemTemplate.
By default, the DataList displays each item as a row in an HTML <table>.
However, by setting the RepeatColumns
property, you can specify how many DataList items should appear per table row. In addition to being able to specify how many DataList items to show per row of the HTML <table>, you can also specify that the contents of the DataList should be displayed using <span>
tags instead of a <table>
tag. The DataList’s RepeatLayout property, which can be set to either Table or Flow, dictates whether the data in the DataList is rendered in an HTML <table>
or in <span>
tags.
With its templates and RepeatColumns
and RepeatLayout
properties, it’s obvious that the DataList allows for much more customization of the rendered HTML markup than the DataGrid. This increased customization can lead to more user-friendly displays of data with the DataList, as the DataGrid’s “single HTML <table>
with one table row per DataSource
record” model might not always be the best fit for presenting information. However, to ascertain the usability of the DataList it is not sufficient just to examine the customization improvements over the DataGrid; we must also compare the DataGrid’s sorting, paging, and editing functionality to the DataList’s.
With its EditItemIndex template and EditCommand, UpdateCommand, and CancelCommand events, the DataList can support inline editing. However, adding such functionality with the DataList takes more development time than with the DataGrid. This disparity in development time is due to two reasons:
While inline editing with the DataList is not terribly difficult, the same cannot be said for sorting and paging of the DataList’s data. While such functionality is most definitely possible with some clever programming, adding such functionality to a DataList would take significant development time. Therefore, if it is a requisite that the end-user can sort and page the data, it is likely best to choose the DataGrid over the DataList.
The performance of the DataList is better than that of the DataGrid, most noticeably so when the DataList is in a Web form. Figure 2 shows the results of the Web Application Stress Tool test on the DataList.
Figure 2: Requests Per Second for the DataList
As the results in Figure 2 show, the DataList outperforms the DataGrid most noticeably when the Web controls are placed within a Web form (thereby causing the Web control to emit its ViewState).
Digging Into the Repeater
The Repeater Web control offers the most flexibility in the rendered HTML of all three data Web controls. Unlike the DataGrid or DataList, both of which automatically encase its developer-specified content within predetermined HTML markup, when rendered the Repeater emits strictly the HTML markup you specify. For this reason, if you wish to display data in some way other than in an HTML <table>
or in a series of <span>
tags, you must use the Repeater control.
When using the Repeater, like with the DataList, you specify the markup using templates. The Repeater contains the following five templates:
The HeaderTemplate and FooterTemplate specify the HTML markup to appear before and after the data being bound to the Repeater. The AlternatingItemTemplate and ItemTemplate specify the HTML markup and databinding syntax used to render each record of the Repeater’s DataSource
. For example, imagine that you were binding a DataSet containing employee information to the Repeater, and that one of the fields in the DataSet was EmployeeName
. If you wanted to display a list of employees on a Web page in an unordered list, you could use the following Repeater syntax:
<asp:Repeater runat="server" id="rptEmployees">
  <HeaderTemplate>
   <ul>
  </HeaderTemplate>
  <ItemTemplate>
   <li><%# DataBinder.Eval(Container.DataItem, "EmployeeName") %></li>
  </ItemTemplate>
  <FooterTemplate>
   </ul>
  </FooterTemplate>
</asp:Repeater>
The Repeater class is not derived from the WebControl
class, like the DataGrid and DataList. Therefore, the Repeater lacks the stylistic properties common to both the DataGrid and DataList. What this boils down to is that if you want to format the data displayed in the Repeater, you must do so in the HTML markup. For example, in our example above, if we wanted to display the employee names in a bold font we’d have to alter the ItemTemplate to include an HTML bold tag, like so:
<ItemTemplate>
 <li><b><%# DataBinder.Eval(Container.DataItem, "EmployeeName")
   %></b></li>
</ItemTemplate>
Whereas with the DataGrid or DataList, we could have made the text appear in a bold font by setting the control’s ItemStyle-Font-Bold
property to True.
The Repeater’s lack of stylistic properties can drastically add to the development time metric. For example, imagine that you decide to use the Repeater to display data that needs to be bold, centered, and displayed in a particular font-face with a particular background color. While all this can be specified using a few HTML tags, these tags will quickly clutter the Repeater’s templates. Such clutter makes it much harder to change the look at a later date, especially for others working on the project who have to wade through the mess of HTML syntax. Compare this to specifying the formatting for a DataGrid or DataList. With either of these two controls, you can leave the templates clutter-free by specifying the DataGrid or DataList’s stylistic properties. Additionally, the stylistic properties of the DataGrid and DataList can be set automatically with tools like Microsoft Visual Studio .NET or the ASP.NET Web Matrix.
Along with its increased development time, the Repeater also lacks any built-in functionality to assist in supporting paging, editing, or editing of data. Due to this lack of feature-support, the Repeater scores poorly on the usability scale. Of course, if all you are interested in is displaying data without any fancy bells or whistles, the Repeater’s lack of features in not a major detractor. I stress the word “if” because typically once a Web application is deployed users find that they want additional features, such as sorting, paging, and editing.
The Repeaters one redeeming quality is-not surprisingly-its performance. The Repeater’s performance is slightly better than that of the DataList’s, and is more noticeably better than that of the DataGrid’s. Figure 3 shows the number of requests per second the Repeater could handle versus the DataGrid and DataList.
Figure 3: Requests per Second for the Repeater
Conclusion
When displaying data in an ASP.NET Web page, many Web developers choose the data Web control they are most familiar with, which is typically the DataGrid. However, such blind decisions are not wise as there is no universally “best” data Web control. Rather, when deciding what data Web control to use for a given Web page, ask yourself a variety of questions to determine which control is best suited for the task at hand. Do you want to allow the user to sort through the data? Does the data need to be presented in a format other than an HTML ? Will this page be heavily visited, thereby making performance a key concern?
The DataGrid Web control provides the greatest feature set of the three data Web controls, with its ability to allow the end-user to sort, page, and edit its data. The DataGrid is also the simplest data Web control to get started with, as using it requires nothing more than adding a DataGrid to the Web page and writing a few lines of code. The ease of use and impressive features comes at a cost, though, namely that of performance: the DataGrid is the least efficient of the three data Web controls, especially when placed within a Web form.
With its templates, the DataList provides more control over the look and feel of the displayed data than the DataGrid. Using templates, however, typically requires more development time than using the DataGrid’s column types. The DataList also supports inline editing of data, but requires a bit more work to implement than the DataGrid. Unfortunately, providing paging and sorting support in the DataList is not a trivial exercise. Making up for these lacking built-in features, the DataList offers better performance over the DataGrid.
Finally, the Repeater control allows for complete and total control of the rendered HTML markup. With the Repeater, the only HTML emitted are the values of the databinding statements in the templates along with the HTML markup specified in the templates-no “extra” HTML is emitted, as with the DataGrid and DataList. By requiring the developer to specify the complete generated HTML markup, the Repeater often requires the longest development time. Furthermore, the Repeater does not offer built-in editing, sorting, or paging support. However, the Repeater does boast the best performance of the three data Web controls. Its performance is comparable to the DataList’s, but noticeably better than the DataGrid’s.
Happy Programming!
Benchmark Settings
The tests were run on a Microsoft Windows 2003 Server laptop with a 2.4 GHz Intel Pentium 4 processor, 512 MB of RAM, and a 30GB Ultra ATA hard drive. The Web server used was IIS 6.0; ASP.NET version 1.1 was used. The Web Application Stress Tool was configured to use a single thread in its testing, with no warm-up or cool-down requests made. Each test was run for a one-minute duration.
For more on performance testing of the data Web controls, as well as other great ASP.NET performance information, check out Scott Guthrie’s ASP.NET Performance Talk from TechEd 2003. Additionally, you can download the demos from his talk.
Recommended Links:
*This article originally appeared on the ASP.NET Dev Center at MSDN
Scott Mitchell, author of five ASP/ASP.NET books and founder of 4GuysFromRolla.com, has been working with Microsoft Web technologies for the past five years. An active member in the ASP and ASP.NET community, Scott is passionate about ASP and ASP.NET and enjoys helping others learn more about these exciting technologies. For more on the DataGrid, DataList, and Repeater controls, check out Scott’s book ASP.NET Data Web Controls Kick Start (ISBN: 0672325012). Read his blog at : http://scottonwriting.net