Simplified and Extended Data Binding Syntax in ASP.NET 2.0(part1)


The server-side data binding techniques that were introduced in ASP.NET version 1.0 revolutionized the way developers build pages that access data. No longer was there a requirement for complex and lengthy code sections that build up HTML tables or lists of values. However, using ASP.NET 1.x, you still have to write code to perform the data access and expose the data to the list or grid controls for data binding.

In version 2.0, new data source controls can be used to remove the need for any code at all, while still providing a whole range of features for extracting data that can be filtered, sorted and paged for display. They also support automatic updates to data for the new GridView, DetailsView and FormView controls, making it extremely easy to build data access pages with little or no server-side code being required.

To support these features, there have been both simplifications and extensions to the syntax used for data binding. The syntax used in version 1.x can be confusing, cumbersome, and is tedious and to write. In version 2.0, data binding statements are more concise, easier to use, and reduce complexity (of course, the existing version 1.x syntax is still supported). Plus, for hyperlinks in the new GridView control, you can now specify more than one column or expression for binding to the control; allowing more than one value to be used when constructing the URL (href) attribute of the resulting hyperlink.

And, more than this, there are three new types of data binding statement you can use. OK, it may seem that this makes nonsense of the simplifications just described, but in fact these additions provide broader opportunities for data binding. There are two new expressions aimed at supporting XML data with the new data source controls added to version 2.0 of ASP.NET. There is also a new expression to provide two-way data binding in controls that support no-code automatic updating of the source data.

This article looks at:

  • The simplification of, and extensions to, the ASP.NET 1.x data binding syntax
  • The new two-way data binding syntax for updating data sources
  • The new syntax for binding to XML data in ASP.NET 2.0

The Simplified Data Binding Syntax in ASP.NET 2.0

Many developers have questioned the verbose and seemingly inflexible nature of the statements that are required to perform data binding to ASP.NET list controls such as the Repeater, DataList and DataGrid. Plus, when writing pages in C#, it's not unknown for data type conversion issues to arise, because C# does not perform the same level of implicit data type conversion as Visual Basic .NET.

The Existing Data Binding Syntax in ASP.NET 1.x

In its simplest form, the format for data binding in ASP.NET 1.x is:

In a list control, expression is usually the column name. For example, this code inserts the value from the CustomerName column in the current row into a Label control (notice the use of single quotes to enclose the data binding statement, which itself contains double quotes): 
However, any valid expression that returns a value can be used in a data binding statement. And the same syntax can, of course, be used outside list controls. For example, it can be used to display a value directly in the page, or as the value of an attribute for any other server control. 

The limitation with this simple syntax is that values cannot be formatted. Instead, you must use the Eval method of the object that is exposing the data, referenced through the static DataBinder object. This method has two overloads, one of which takes an additional parameter that specifies the formatting to be applied to the value:

The format parameter is a String value, using the value placeholder replacement syntax (called composite formatting) like his: 
The placeholder is always zero in ASP.NET 1.x, and the format string following the colon can be one of the predefined characters (such as C for currency, or t for the short version of the time), or a custom format string made up of a combination of text and formatting characters. The format string "{0:dddd d MMM}" shown in the code above produces output of the form: Monday 24 May. 

Notice the underscore at the end of the second line in the previous code listing. The data binding statement is code that is executed to produce the value that is displayed, and so when writing pages using Visual Basic .NET you must include the line continuation character if you break the code over more than one line. It is not required if you are writing the page in C#, or any language that does not depend on carriage returns to signify the end of a code line.

For details of the characters and syntax used in formatting strings, see: For details of the composite formatting syntax, see:

Data Binding Statements in ASP.NET 2.0

One of the reasons that the two different approaches to the data binding syntax were originally made available is that using the Container object is more efficient at runtime than the Eval method of the DataBinder object. This is because the Eval method uses late-bound reflection to determine the value type. However, this difference is marginal in almost all cases.

In ASP.NET 2.0, you should generally use the Eval method. And, to make this easier, the DataBinder object that exposes it has been made the default context for all non-hierarchical (rows and columns) data binding expressions. This means that you can use a much simpler syntax. If you just want to display a value without formatting it, use the Eval method directly:

Or, if you need to format the value, use the second overload that accepts a format string: 
The format parameter works here just like it does in v1.x. So, for example, you can format the value in a column named Price as currency using: 
And, as in v1.x, you can use more complex format strings to display text as well as the current row value: 
Using Multiple Data Bound Values in a Hyperlink Control 

Another area where ASP.NET 2.0 extends the data binding syntax of v1.x is when you use a HyperLinkField in the new GridView or DetailsView controls. We don't have room to cover these controls in detail here, though any developer who has to display hierarchical data will no doubt have already headed straight for these great new controls and experimented with their capabilities. They can be used in conjunction with the new data source controls to provide "no-code required" display of data from almost any data source. For example, this is all you need to display the contents of the Products table in the sample Northwind database in SQL Server:

The screenshot below shows the results. This example, basic-binding.aspx, is included in the samples you can download for this article from 

Figure 1

However, the new data binding capability comes to light once you turn off automatic column generation by adding the attribute AutoGenerateColumns="False" to the declaration of a GridView control, or AutoGenerateRows="False" to the declaration of a DetailsView control. You can then declare a HyperLinkField control within the <Columns> section of the GridView control, or within the <Rows> section of the DetailsView control.

The DataNavigateUrlFields Property

The new HyperLinkField control exposes a property named DataNavigateUrlFields, which is broadly equivalent to the DataNavigateUrlField property of the HyperLinkColumn you would use in a DataGrid control in v1.x. But, as the name suggests, it accepts more than one column name or expression. In the control declaration, you specify the column names as a comma-delimited list, for example:

There is also a DataNavigateUrlFormatString property exposed by the HyperLinkField control - just like the HyperLinkColumn control in version 1.x. The useful feature with the HyperLinkField control is that you can now take advantage of ability of the DataNavigateUrlFields property to bind to multiple columns, and insert more than one value from the current row into the NavigateUrl (the href attribute) of the resulting hyperlink. 

As an example, the code below uses feature to provide a hyperlink that contains two values, both extracted from the current row of the Customers table, for the href attribute:

The resulting value for the href attribute will be something like this: 
The screenshot below shows the results. This example, hyperlinkfield.aspx, is included in the samples you can download for this article from 

Figure 2

Setting the DataNavigateUrlFields Property at Runtime

You can also set the DataNavigateUrlFields and DataNavigateUrlFormatString properties at runtime using code. To set the DataNavigateUrlFields property you must create a String array and assign it to the DataNavigateUrlFields property during the Load event of the parent GridView or DetailsView control:

The code above is in Visual Basic .NET. The equivalent in C# is shown below. Notice that the control name (GridView1) is referenced directly, because the sender parameter is of type Object and cannot be implicitly converted to a GridView type (and, hence, does not have a Columns collection): 

The New Two-Way Data Binding Syntax

When building pages that use list or grid controls in ASP.NET 2.0, the new data source controls make it much easier than the v1.x approach of using code in the page to generate a DataReader or DataSet instance, and then binding this to the control. In version 2.0, you simply place a data source control on the page, and link it to the list or grid control using the DataSourceID attribute of property of the control. You saw an example of this in the earlier section "Using Multiple Data Bound Values in a Hyperlink Control".

This approach can be used with any of the list controls that are provided with ASP.NET 2.0, including those that were originally introduced in version 1.0 (for example, the DataGrid, DataList, Repeater, ListBox, and HtmlSelect controls). However, data source controls really come into their own when used with the new GridView, DetailsView and FormView controls.

Automatic Updates with the New Data Source Controls

The original version's (1.0) list and grid controls are effectively "read-only", in that you have to write code that is executed in response to events raised by controls within the list or grid (for example, when the user clicks an Update or Delete link). This code must collect the values in the relevant row and then execute some code you've written to push these values back into the data store - possibly using stored procedures or explicit SQL statements. In other words, data binding is only being used to populate the list or grid control.

In the GridView, DetailsView and FormView controls, this is no longer the case. As long as the data source is updateable, and you have provided the appropriate update, insert and delete commands, the control will automatically push changes to the values in the list or grid control to which it's attached back into the data source. You can specify the update, insert and delete commands as explicit SQL statements or use stored procedures if you need to interact with a more complex database table structure.

What's important with respect to the topic of this article, however, is how these new controls affect the syntax used for data binding. When the columns or rows for a GridView or DetailsView control are auto-generated, or specified using a the pre-defined field types such as BoundField, HyperLinkField, or CheckBoxField, the data source control can figure out what to do when it's time to push changes back into the data store by looking at which columns each of the field types is bound to.

But, if you use a TemplateField in a GridView or a DetailsView, you must declare all the content for that column or row yourself, just as you would when using a TemplateColumn in a DataGrid control. And, if you use a FormView control, you always have to declare all the content yourself. Like the v1.0 Repeater control, the FormView control does not support pre-defined column types - it uses only templates for content generation.

Inside the templates of a TemplateField, or in the templates of a FormView control, you use data binding statements to connect the controls you declare there with the columns in the data source control. The interesting point is that the data binding technology must, in this case, support both "read" and "write" operations, rather than being "read-only" as has always been the case in the past. This is termed two-way data binding, and is supported through a new method called Bind.

The Bind Method

As with the Eval method, the Bind method has two overloads, which means that it can be used with or without the "format" parameter:

In fact, other than specifying the new method name, the Bind method is used just like the Eval method. To bind an attribute of a control to the CompanyName column, you use: 
If you want to bind an attribute of a control to a value that requires formatting, you add the format parameter: 
To demonstrate the Bind method, the following code shows a SqlDataSource control with parameterized SQL statements specified for the UpdateCommand and InsertCommand property attributes. The data source control exposes a two-column rowset containing the ID and name of products from the SQL Server Northwind sample database: 
The next listing shows how the templates of a FormView control can be declared to allow the product name to be edited or a new product to be added. For this to work, the FormView control must know which is the primary key column in the source data, and this is declared using the DataKeyNames attribute (multiple column primary keys are specified using a comma-delimited list of column names in the control declaration, or a String array of column names at runtime). 
Then each template section declares a control to either display or allow editing of the product name. In the ItemTemplate, where the value is just being displayed, the code can use the Eval method to bind to the ProductName column. In the EditItemTemplate and the InsertItemTemplate, the product name is displayed in a TextBox control, allowing it to be edited or entered. Because we want to push these values back into the database, the Bind method must be used here. 

One important point to note is that the ProductID column is the primary key in the table, and so it is "read-only" and cannot be changed in the EditItemTemplate. However, it is required to populate the @ProductID parameter of the SQL UPDATE statement - which means it must be placed in an ASP.NET server control (in this case a Label) and bound to the source rowset using the Bind method. If the Eval method is used here, the control will not be able to populate the @ProductID parameter in the SQL statement.

The ProductID is not required in the InsertItemTemplate, because this is an IDENTITY column in the database - and so it will be populated automatically when a new row is added. For this reason, the SQL INSERT statement has no parameter for the ProductID; hence, there is no requirement to display the value in a server control within this template, or use the Bind method. The only value that is required is the new product name, and the Bind method used with the TextBox where this is entered will push the new value into the database table.

The screenshot below shows the results. This example, bind-method.aspx, is included in the samples you can download for this article from

Figure 3

To cause an update, delete or insert operation to take place in a FormView control, you must provide the relevant links or buttons to initiate the process yourself. However, as long as you use the appropriate values for the CommandName property attributes ("Edit", "New", "Update", "Insert", "Delete" or "Cancel") the control will automatically wire them up to the events so that you don't have to write any code. For more details of the FormView control, see the System.Web.UI.WebControls namespace in the Reference section of the SDK installed with the .NET Framework, or available online from

When To Use the Bind Method

When you use templates in a GridView, DetailsView or FormView control, you should be aware of a few points:

  • The Bind method is responsible for providing the values for the parameters declared in the SQL statements that push changes to the data back into the database. Therefore, all the controls that provide values for the parameters in the SQL statement for the current operation must use the Bind method. In the earlier example, the control for the ProductID in the EditItemTemplate is a Label that doesn't allow the value to be edited (it is the primary key for the row). However, the value is required to populate the @ProductID parameter in the SQL UPDATE statement, and so the Bind method is used, rather than the Eval method. However, because ProductID is an IDENTITY column within the database, a value isn't required in the SQL INSERT statement - and a bound control is not required in the InsertItemTemplate section.

  • In general, the Bind method should only be used in an EditItemTemplate and an InsertItemTemplate. It should not be used (or, in fact, required) in an ItemTemplate, AlternatingItemTemplate, or SelectedItemTemplate.

  • A list control in which the Bind method is used must be populated by a data source control that is connected to the list control through the DataSourceID property or attribute. It cannot be used for controls that are populated (as in ASP.NET 1.x) by assigning a rowset to their DataSource property.

  • Every control that uses the Bind method to populate one or more of its attributes must have a unique user-declared value for its ID property (as shown for the controls in the listing above).

  • The Bind method cannot be used in a DataList or a Repeater control, or in any other type of control, and it cannot be used at Page level outside all of the controls. In effect, the only controls to where you can use the Bind method are the GridView, DetailsView and FormView controls.
想对作者说点什么? 我来说一句