Search

Deciding When to Use the DataGrid, DataList or Repeater Part 1

0 views

Web development has come a long way since simple script-based Web programming technologies like Microsoft Active Server Pages (ASP). With Microsoft ASP.NET, a lot of the tedious, repetitious coding chores that were commonplace with classic ASP are now a thing of the past. For example, as all one-time classic ASP developers know, displaying data in a classic ASP Web page required the following pseudocode: Create connection to the database Populate an ADO Recordset with a SQL query Display any header HTML needed For Each Record in the Recordset &nbsp&nbsp Print out the Recordset field(s) and associated HTML &nbsp&nbsp Move to the next record Next Display any footer HTML needed For example, to display the contents of a Recordset in an HTML <table>, a developer would have to emit the HTML markup for the <table> tag, then loop through each record in the Recordset, emitting a single <tr> tag per loop, and a number of <td> tags along with the values of the Recordset fields she was interested in displaying. Finally, after the loop, the developer would need to emit the closing <table> tag. This approach required by classic ASP has one major disadvantages: it tightly integrates the HTML content with the ASP Web page's source code. By not separating the code and HTML content, it is exponentially more difficult to make changes to the HTML content, especially for graphic artists or Web designers who might not be savvy with programming technologies. Furthermore, this integration of code and HTML content requires a relatively large amount of code, since code is needed for both retrieving the database results and emitting its contents. Fortunately, ASP.NET offers three controls that make displaying data in an ASP.NET Web page overwhelmingly simpler than the iterative approach required in classic ASP. These three controls, which I will refer to henceforth as the data Web controls, are the DataGrid, DataList and Repeater. Chances are, if you've already developed ASP.NET Web pages you have already had some experience with at least one of these three controls. Most commonly, developers start learning about the DataGrid, due to the ease with which it can be used and its ability to allow for sorting, paging and editing of its data. However, the DataGrid is not always the best choice for a control when displaying data in an ASP.NET Web page. In this article, we will examine the unique traits of each of the data Web controls. These traits give each data Web control a number of advantages and disadvantages. Since each data Web control has some disadvantage, there is no "perfect" control for any job. In deciding what control to use you must weigh the benefits and demerits of each of the three data Web controls and decide what the best control to use is. To aid in our comparison, when examining each of the data Web controls we'll focus on three metrics: usability (from the perspective of the Web visitor), development time and performance. We'll start with a quick look at the similarities among the three data Web controls. Next, we'll delve into an examination of the DataGrid, and then move onto the DataList, and finally look at the Repeater. With each control we'll look at the controls' features and discuss how its feature set affects these metrics.

Similarities Among the Data Web Controls

Before we examine the differences among the data Web controls that make them unique from one another, let's first look at their similarities. The most general similarity is that, from a very high-level point of view, the DataGrid, DataList and Repeater were all designed to do roughly the same thing: display data. Another similarity is the code needed to bind data to the data Web controls. Specifically, only two lines of code are needed: dataWebControlID.DataSource = someDataSource dataWebControlID.DataBind() Typically the someDataSource object assigned to the data Web control's DataSource property will be a DataSet, SqlDataReader, OleDbDataReader or a collection (such as an Array, an ArrayList or some other class in the System.Collections namespace). However, any object that implements the IEnumerable interface can be bound to a data Web control. The DataBind() method enumerates the records of the specified DataSource. For each record in the DataSource, an item is created and appended to the data Web control's Items collection. Each item in a data Web control is an instance of a class. The specific class used for each of the control's items depends on the data Web control. For example, each item in the DataGrid is an instance of the DataGridItem class, whereas each item in a Repeater is an instance of the RepeaterItem. Each data Web control uses a different class for each of its items because it is how these items are rendered that determines the HTML markup generated by the data Web control. For example, the DataGridItem class is derived from the TableRow class, meaning that each DataGridItem renders, more or less, as a table row. This makes sense since the DataGrid is designed to display data in a tabular format within an HTML <table> tag, where each item is rendered as a single row in an HTML <table>. The Repeater, on the other hand, is designed to allow for complete customization of its output. Therefore, it's not surprising that the RepeaterItem class is not derived from the TableRow class. Another similarity among the data Web controls is that each control is capable of using templates to provide a highly customizable output. The DataList and Repeater controls must use templates to specify their content, whereas the DataGrid can optionally use a template for a particular column via the TemplateColumn column type (We'll discuss the various DataGrid column types in the next section, "Examining the DataGrid Web Control."). One final comparison worth noting is that both the DataGrid and DataList controls are derived from the WebControl class, while the Repeater control is derived from the Control class. The WebControl class contains a number of aesthetic properties, such as BackColor, ForeColor, CssClass, BorderStyle and so on. This means that with the DataGrid and DataList you can specify stylistic settings through the properties it inherits from the WebControl class. The Repeater, however, does not have any such stylistic properties. As we'll discuss in the "Digging Into the Repeater" section, any visual settings to the Repeater's output must be specified in the Repeater's templates.

Examining the DataGrid Web Control

Among the three data Web controls, the DataGrid Web control is by far the most versatile in its features, but is the least flexible when it comes to customizing the actual HTML markup generated by the control. This inflexibility in the rendered HTML markup is due to the fact that the DataGrid is designed to display data in a tabular format using an HTML <table>. Therefore, for each record being bound to the DataGrid, a single table row (<tr>) is created, and for each field in the record that is to be displayed, a single table column (<td>) is created. The DataGrid comes packaged with a number of features that can greatly increase the usability of the data being displayed. For example, by setting the DataGrid's AllowSorting property to True and adding just a bit of source code, developers can turn an ordinary DataGrid into one whose data can be sorted by the end user. Additionally, with just a bit more work, a developer can enhance the DataGrid to allow for data pagination, or inline editing of the data. These features clearly bolster the usability of the DataGrid. In addition to its high marks in the usability field, the DataGrid also offers short development time. To get started displaying data on an ASP.NET Web page using a DataGrid, one only needs to add a DataGrid to the Web page and write two lines of code needed: the first to bind the data to the DataGrid's DataSource, and the second to call the DataGrid's DataBind() method. Clearly, as the number of features added to the DataGrid increases, so does the development time, but compared this development time to the other data Web controls. Imagine that you wanted to allow sorting of the data displayed by the Repeater. Adding such functionality is definitely possible, but would require significantly more time and energy than to do the same with the DataGrid. Despite the DataGrid's impressive usability and development time ratings, there are two disadvantages inherent with this control. First, as touched upon earlier, the DataGrid is very limited in the customization of the rendered HTML markup. Yes, you can customize the fonts, colors, and borders of the DataGrid's various rows and columns, but the fact still remains that when the DataGrid displays your data it will be in an HTML <table> with a <tr> for each record in the DataSource and a <td> for each field. Specifically, each column in a DataGrid is an instance of a class that is derived from the DataGridColumn class. There are five built-in DataGrid column types:
  • BoundColumn
  • ButtonColumn
  • EditColumn
  • HyperLinkColumn
  • TemplateColumn
  • Each of these column types presents data or provides some sort of interface to allow the user to interact with the DataGrid. For example, the BoundColumn displays the value of a DataSource field as plain text, while the HyperLinkColumn displays a hyperlink whose text and URL portions can be DataSource fields. In addition to these built-in column types, custom DataGrid column types can be created by creating a class that is derived from the DataGridColumn class. (An example of creating a column that extends the BoundColumn functionality in limiting the number of characters displayed can be seen in Creating a Custom DataGridColumn Class.) With the variety of DataGrid column types, it might not make sense as to why the DataGrid's rendered HTML markup is not highly customizable. Realize that while each DataGrid column type emits different HTML when rendered, each column is wrapped in a set of <td> tags, and each row is contained in a set of <tr> tags. So, even though a TemplateColumn can be used to customize the HTML output of a particular column for each row, the DataGrid will still render as an HTML <table> with a <tr> for each row and a <td> for each column. This limitation of the DataGrid prohibits more creative displays of data. For example, if you want to display, say, five records per table row, the DataGrid is not a candidate; rather, you must use either the DataList or Repeater. Furthermore, if you want your data to display in HTML markup other than a <table>, you are flat out of luck with the DataGrid. A second disadvantage of the DataGrid is its performance. The DataGrid has the worst performance out of the three data Web controls. On top of this, the ViewState produced by the DataGrid-especially DataGrids with a large number of rows-can be extremely large. If you are using a DataGrid simply to display data, you can turn off the ViewState, but this is not an option when utilizing the DataGrid's sorting, paging, or editing features. To measure the performance of the DataGrid, I used Microsoft's free Web Application Stress Tool (WAST). The precise testing conditions and WAST settings are listed at the end of this article in the "Benchmarks Settings" section. Also, the code used for the tests is available for download at the end of this article. The Web Application Stress Tool bombards the Web server with requests to a specific set of URLs. For each of these tests I had one URL continually requested as fast as possible for one minute. WAST reports a number of performance metrics; the one I decided to concentrate on was requests per second, which indicates how many times the Web server could execute the ASP.NET Web page per second. Two tests were run against a simple DataGrid that merely displayed data. Specifically, the DataGrid displayed four fields from the Northwinds database's Customers table (The Customers table contains a total of 91 records.). The DataGrid's AutoGenerateColumns property was set to True. The first test placed the DataGrid inside a Web form (a <form runat="server">), while the second one did not. By putting a control in the Form and not explicitly setting its EnableViewState property to False, the control persists its state using the ViewState. Creating this ViewState entry can be a time-consuming process, reducing the overall requests per second that can be processed, as the results show in Figure 1. Figure 1: Requests Per Second for the DataGrid As we will see when examining the DataList and Repeater, both these controls offer better performance than the DataGrid. *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

    Suggest a Correction

    Found an error or have a suggestion? Let us know and we'll review it.

    Share this article

    Comments (0)

    Please sign in to leave a comment.

    No comments yet. Be the first to comment!