Chapter 9 The Data-Binding Model

Overview

To write effective ASP.NET 1.x data-driven applications, you need a deep understanding of ADO.NET objects. You have to be familiar with connections, commands, transactions, parameters, and all the objects we dealt with in the previous two chapters. In ASP.NET 2.0, the role of ADO.NET object is more blurred because of the introduction of a new family of data-related and more programmer-friendly components the data source objects. In ASP.NET 2.0, you use ADO.NET objects directly much less frequently. You also use them in relatively standard data-driven pages belonging to relatively simple or prototype Web sites. Does this mean that ADO.NET objects have suddenly become unnecessary? Will ASP.NET 2.0 magically let you write data applications without having to really know about databases? Of course not.

Complex and sophisticated enterprise systems typically isolate ADO.NET code in the data tier, and they often have it wrapped up by an additional layer of helper libraries such as the Microsoft Data Access Application Block. Realistic pages belonging to similar systems never call ADO.NET objects directly, like we did in the demonstration pages of the past two chapters. In ASP.NET 2.0, ADO.NET objects are still essential pieces of the .NET Framework, but they have been pushed into the back-end infrastructure of most common data-binding operations. ASP.NET 2.0 offers the possibility of writing data access code that hides many essential steps from view and buries them in the framework's code. Basically, what many ASP.NET 1.x developers called "that boring ADO.NET boilerplate code" is now packed into a bunch of new data source controls.

Overall, the data-binding model of ASP.NET is founded on three pillars: data-binding expressions, classic data source-based binding, and data source controls, which are limited to ASP.NET 2.0. Let's start with data source-based binding, which is probably the most common form.