Take Advantage of Two-Way Data Binding in ASP.NET

ASP.Net has raised the bar for Web development considerably with very rich developer functionality built into a flexible and highly extensible object model. For developers who come from a background of hand coding ASP or other scripting or CGI style technology .Net seems almost too good to be true as it reduces a lot of redundant code and simplifies the development process significantly.

But one area, simple data binding for controls like textboxes, checkboxes, radio buttons and so on leave a lot to be desired both in terms of ease of use for binding the data as well as providing the ability to read the data back into the data source.

Unfortunately, I personally think that data binding in ASP.Net doesn’t go nearly far enough. First the process of assigning data sources is cumbersome at best using either a slow and work extensive designer or alternately by having to embed yet another script based markup tag (<%# %>) into source code. Both are way too cumbersome if you’re dealing with a lot of data on a regular basis.

But more importantly data binding in ASP.Net is one way only. You can only bind to data but there’s no mechanism to unbind the data from the control back into its underlying datasource. It’s hard to really call ASP.Net’s mechanism data binding because really what it is is a data display mechanism.

To clarify this, there are really two types of data binding in ASP.Net. There’s list based data binding of the type that you use to bind data to a ListBox or a DataGrid. This mechanism actually works very well and provides a good amount of flexibility. This is also primarily a display mechanism – you tend to display data or lists with this type of binding.

Then there is simple Control Data binding which basically binds to a single value to a property of a control. A text box binding to a field of the database is an example of simple data binding. This also tends to be the most common data binding that most people do during data entry and the one that is the most time consuming.

And here is where the problem lies – the control binding here is one way and involves some convoluted syntax that isn’t even property based.

How things work now

Let me give you an example to put the current process into perspective. Assume that I have a business form and want to display and edit some customer information. So I use my business object to load up a dataset with data from a Load() method which internally populates a DataSet and DataRow member (you could also do this manually in your code of course). I now have a Dataset that I can bind to the various controls. This is easily done by using the control’s data binding options in the property sheet or by manually assigning the value using the ASP.Net data binding scripting syntax (yes another variation of <% %> syntax using <%# %>).

Data binding in ASP.NET 1.x was unidirectional, i.e., the control could in no way update the underlying data source to which it was bound. While ASP.NET 2.0 introduced two-way data binding, not all the ASP.NET controls supported it, you need to write custom data binding logic to make two-way data binding available for all the controls.