Relational Data Binding in ASP.NET

Relational Data Binding in ASP.NET

One of the great features introduced into ASP.NET in version 1.0 was server-side data binding, through a range of ASP.NET server controls and to many different kinds of data structures. This includes the ADO.NET DataTable and DataReader, as well as other collection-based structures.

In version 2.0 of ASP.NET, this concept has been extended to allow developers to build data-bound pages that no longer require any code to be written—even for complex operations such as paging, sorting, and updating the original data.

ASP.NET server controls expose a property named DataSource to which you assign the source data structure. For example, if you have an active instance of a DataReader, you simply assign it to the DataSource property of the control and then call the DataBind method (on the control or on the Page object that contains it) to cause the control to iterate through the data rows and generate the output in the page:

MyDataGrid.DataSource = MyDataReader
MyDataGrid.DataBind()

If the data source contains more than one table, for example, when using a DataSet, the DataMember property of the control is used to specify which table is to be bound:

MyDataGrid.DataSource = MyDataReader
MyDataGrid.DataMember = "TableName"
MyDataGrid.DataBind()

ASP.NET Data Source Controls and the GridView Control

In version 2.0, ASP.NET introduces a range of new server controls to handle data management and server-side data binding. These controls fall into two distinct groups:

Several data source controls are included with ASP.NET, all residing in the System.Web.UI.WebControls namespace. These include controls designed to work with relational data from SQL Server, OLE-DB and ODBC databases, Microsoft Access, and Oracle. There is also a special data source control designed to work with the new ObjectSpaces technology to enable server-side data binding to custom business objects. Some data source controls consume XML from a stream or disk file. The XML Data Source Controls and Data Binding section in Chapter 7 briefly discusses the controls that consume XML, and the companion book to this one, A First Look at ASP.NET v. 2.0 (Boston, MA: Addison-Wesley, 2004, ISBN 0-321-22896-0), contains full details of all the data source controls.

The new ASP.NET GridView and DetailsView controls expose Data Source and DataMember properties, just like most other "bindable" server controls. However, they also expose a DataSourceID property, which can be set to the ID of a data source control that exposes data in relational (columns and rows) format. When this is done, the two controls work together to extract the data and perform the server-side data binding automatically, with no code required.

You'll also be pleased to know that all the ASP.NET server controls that support data binding now expose the DataSourceID attribute in version 2.0, so they can be used interchangeably with any data source control that exposes the data in the appropriate format.

An Example of the Data Source and GridView Controls

As an example of how these two controls change the whole approach to server-side data binding, the code in Listing 1.1 (taken from the book referred to above) shows the complete <form> section of an ASP.NET page that extracts some rows from the Northwind database and displays it in a GridView control.

Using a Data Source Control and a GridView Control

<form runat="server">

<asp:SqlDataSource id="ds1" runat="server"
  ConnectionString="server=localhost;database=Northwind;uid=x;pwd=x"
  SelectCommand="SELECT ProductID, ProductName, QuantityPerUnit,
                 UnitPrice, UnitsInStock, Discontinued FROM Products"
/>

<asp:GridView id="grid1" DataSourceID="ds1" runat="server" />

</form>

The SqlDataSource control uses a connection string and a SQL statement (it could alternatively be a stored procedure name), plus "sensible" default settings, to connect to a database and extract the data rows. It reacts to the page-level events that occur when the page is requested and internally builds the usual ADO.NET objects it needs (Connection, DataAdapter, DataSet, and so on).

The GridView control performs the data binding and displays the data. The screenshot in Figure shows the result. It displays all the rows from the Products table in the Northwind database, just as specified in the SQL statement. However, notice the Discontinued column. This is a Boolean field in the table, and the control automatically displays it using read-only (disabled) checkboxes.

Do I Still Need to Write ADO.NET Code?

In ASP.NET, you may be able to avoid writing code to interact with a database and just rely on the data source controls to do all the work. However, that doesn't mean you can stop reading now! As is always the case, knowing more about how the data access technologies actually work, as well as being able to take advantage of the features they offer to tailor performance and behavior to suit your requirements, is part of the development process.

In particular, you may prefer to take advantage of specific new features in ADO.NET such as MARS, asynchronous processing, and batch command execution to access and expose your data in exactly the way you require. In this case, having generated your data structure, you can continue to benefit from server-side data binding by using the new or existing controls through their DataSource and DataMember properties.