Chapter 16: ASP.NET Server Controls and Data Binding

Chapter 14 discussed the basics of data binding in Web Forms and ASP.NET data-bound controls. You also saw how to use data-bound controls in Web applications. Chapter 15 discussed how to develop data-driven Web services and how to access the functionality implemented in a Web service from Web Forms applications. This chapter is an extension of Chapter 14. This chapter concentrates on the more practical aspects of data binding and Web Forms data-bound controls.

Data Binding in Web Forms, Revisited

In Chapter 7, you learned about data binding in Windows Forms and the classes used in data binding. Data binding in Web Forms is totally different than in Windows Forms. Data binding in general is a process of binding some data to some property of a control at runtime. In other words, it allows you to set a value of some property of a control at runtime. The data being bound to a control doesn't have to be a database. It can be any data source including text, collections, expressions, methods, or even properties of other controls. Because this book is about ADO.NET, we'll use a database as our data source.

Before writing applications, you should understand the data-binding model in Web Forms. The following sections discuss the key concepts of Web Forms data binding.

Read-Only Data Binding

Windows Forms data binding is bidirectional, which means Windows Forms controls keep binding state with the data source and allow both read and write methods.

Unlike Windows Forms, the data binding in Web Forms is read only. Providing bidirectional data binding in Web Forms is costly, which is one of the main reasons Web Forms don't support bidirectional data binding.

Another reason why data binding in Web Forms is read only is because most of the data you access through Web applications is read only. For example, say you go to a site such as Microsoft, MSN, your bank, or Amazon. What you do? You search for the thing you're looking for, and then read it or print it. That's it. So who needs data write features? Only people who are responsible for updating the data need data write features. And most of the applications don't update data through the Web interface. Site administrators usually access data on their local servers through Windows Forms or other interfaces.

Even though Web Forms provide read-only data binding, you can't ignore the possibility that people may want to update (write) data through Web Forms applications. For instance, say a bookstore or an online newspaper agency has a Web site and its editors want to update the site content from all over the world.

So how do you provide this data update functionality in Web Forms? You have to implement your own logic. In this chapter, you'll not only see how to implement this logic, but you'll also see how to write some ready-to-run Web applications that you can use in your Web projects.

Simple and Complex Data Binding

Similar to Windows Forms data binding, Web Forms also support two types of data binding: simple data binding and complex data binding. In simple data binding, controls can bind and display one data value at a time. Some of the controls that participate in simple data binding are the TextBox, Button, Label, and Image controls. For example, these controls can only display a single value of a single column of a database table. On the other hand, complex data binding allows controls to bind and display multiple data records. For example, the Repeater, DataList, and DataGrid controls can display multiple records from multiple columns of a database table. The controls used in simple data binding are called simple data-bound controls, and the controls used in complex data binding are called complex data-bound controls.

Note

See the "Understanding Data Binding in ASP.NET" section of Chapter 14 for more details on simple and complex data binding and data-bound controls.

The Roles of the Control and Page Classes in Data Binding

The Control class defined in the System.Web.UI namespace provides the properties, methods, and events that are shared by all ASP.NET server controls. This is the control you would need when you develop your own custom controls. Even though this class is defined in the System.Web.UI interface, it doesn't have any User Interface (UI) functionality. You use this class when you're writing your own custom control that doesn't have a UI.

The Page class represents a Web page (an .aspx file) requested from a server that hosts other server controls and works as an ASP.NET Web application. The following class hierarchy shows the relationship between the Control and Page classes:

 System.Object     System.Web.UI.Control         System.Web.UI.TemplateControl             System.Web.UI.Page             System.Web.UI.UserControl 

Here you're only interested in two methods of the Control class: DataBind and OnDataBinding. The DataBind method is responsible for binding a data source to the server control and all its child controls.

Note

When called on a server control, the DataBind method resolves all data-binding expressions in the server control and in any of its child controls. So, if you have a DataGrid, a Label, and a TextBox control bound to some data source and you call control's DataBind method, it also calls the DataBind methods of all the child controls. Usually you call this method through the Page class.

The OnDataBinding method raises the DataBinding event, which occurs when the server control binds to a data source. A typical call to Page.DataBind method looks like this:

 Sub Page_Load(Src As Object, e As EventArgs)  If Not IsPostBack Then    'Bind child controls here   End If   Page.DataBind() End Sub