ASP.NET 2.0 Databinding, Part II

In part I, I talked about DataSource controls and how they enable two way databinding. Table adapters are another new feature of ASP.NET 2.0 that was designed to work with the ObjectDataSource to allow declarative databinding.

What do I mean by declarative? At a high level, declarative simply means you state what you want, not how you want it done (as opposed to imperative, where you say how something should be accomplished). When these terms are applied to ASP.NET, it usually means aspx markup (declarative) or C# code in your code-behind classes (imperative).

Table adapters generate ADO.NET code, specifically SqlDataAdapters and handles all the database connections for you. Using the designer in Visual Studio we can drag and drop tables, specify stored procedures or ad-hoc SQL and VS will generate a strongly typed DataSet based on the shape of the query, and a SqlDataAdapter for each query you add.

The code that is generated by the designers are partial classes, so you can add methods and properties or handle events on the table adapters or the DataSets they return. The usual example is adding validation logic, which is a nice idea, but implementing the validation with the ASP.NET validation controls generally provides a better user experience.

The table adapter classes and the query methods they expose are decorated with attributes that tell the databinding designers they support certain operations. You could implement your own objects that can work with two way binding that persist to a completely different database, or call a set of web services.

The first query you add to a table adapter defines the shape of the DataTable that is generated for you. If this query is a single table select statements, the designer can generate the insert, update and delete methods for you, otherwise you must manually write the SQL.

In part III, I will put the pieces together and look at where two way databinding and table adapters are a good fit.