Raise your hand if you’ve written a web application that couldn’t be cataloged as a data-driven application. I’m betting that you didn’t raise your hand, because the definition of a data-driven application is quite blurred and flexible enough to incorporate nearly everything. Most web applications get data from the middle tier and display it in a nice-looking HTML layout. This common pattern brought framework authors to introduce a semi-automatic mechanism to facilitate the display of data into well-defined UI components. This mechanism is generally known as
data binding.
Data binding is the process that retrieves data from a given data source and associates it to attributes of UI elements. The data source can be virtually any software component that exposes data, including in-memory elements (e.g., arrays, collections), properties of live objects, and stream-based data flows (e.g., result sets from database queries).
I’ll cover key aspects of data binding in ASP.NET Web Forms applications. I’ll start with simple forms of data binding, then discuss the various types of data source controls and data bound controls.
Simple Data Binding Expressions
At its core, ASP.NET data binding is the association between the property of a server control and a server-side calculated value. This association is established at compile time and buried in the folds of the code that ASP.NET auto-generates when it compiles a .aspx page.
Take a look at the code in Listing 1. This code is supposed to use a Label control to display the city that a user selects from a drop-down list. The code compiles just fine, but it doesn’t work. You don’t receive any errors, but nothing happens.
When you use data binding expressions with ASP.NET controls, behaviors are attached to the control’s life cycle through the DataBinding event handler. For example, the Label control in Listing 1 will update its Text property only when it receives a DataBinding event. If there’s no such event, there’s no update. What triggers this event? It’s the page—if you properly instruct it to do so.
As a developer, you have the power to trigger data binding events for individual controls (including child controls) or for all controls within a page. All you do is invoke the DataBind method. Both controls and ASP.NET pages feature this method. To data-bind all the controls in a page, you need code like that in Listing 2.
Calling the DataBind method has the effect of triggering the DataBinding event for all the controls in scope. Subsequently, any controls with a <%# … %> data binding expression will update themselves. Web Figure 1 shows the results from calling the DataBind method on the page created with the code in Listing 1.
Web Figure 1: Data binding in action
If you don’t want to call DataBind on each page in which you intend to use data binding, you can craft a new page class that overrides the OnLoad method. The code in Listing 3 shows how. This code creates the DataBindingPage class, which loads the DataBind method instead of the OnLoad method when the Load event is triggered. Then, all you need to do is derive each page from the DataBindingPage class by using the following code:
public partial class
BindingExpressions : DataBindingPage
{
// Page-specific code goes here.
}Done this way, data binding in ASP.NET Web Forms is similar to data binding in WinForms. You don’t need to explicitly trigger data binding events; you just need to make sure any bindable element is connected to the correct data source. Calling DataBind (even multiple times) doesn’t really have an impact on performance, because all it does internally is play with Boolean flags. During rendering, these flags are checked to determine whether the programmer has explicitly ordered data binding.
There’s a subtle difference between code blocks (<%= … %>) and data binding expressions (<%# … %>). Code blocks can’t be used with ASP.NET controls; they can only be used with plain HTML markup. Data binding expressions can only be used with ASP.NET control markup and require a call to the DataBind method.
Data Source Controls
Data source controls are designed to interact with data bound controls and hide the complexity of the manual data binding process. Specifically, data source controls provide data to data bound controls. They also support data bound controls in the execution of common operations, such as insertions, deletions, sorting, and updates.
There are quite a few data source controls available. The most commonly used controls are:
- ObjectDataSource. This control allows binding to custom .NET business objects that manage data. You need to follow a specific design pattern and include specific elements. For example, you might need to include a parameterless constructor and methods that behave in a certain way for easy mapping to Create, Read, Update, and Delete (CRUD) actions.
- SqlDataSource. This control allows binding to SQL Server data and other OLE DB and ODBC data sources. You specify the name of the provider and the connection string through properties. You specify CRUD actions through SQL parameterized code.
- EntityDataSource. This control allows binding to the results of an Entity Framework query.
- LinqDataSource. This control allows binding to the results of a Language-Integrated Query (LINQ) to SQL query.