RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Implementing Two-Way Control Binding for Web Forms

ASP.NET's native data binding provides only one-way data binding. With a little bit of effort, it's possible to extend the native functionality and provide flexible two-way data binding and a few other simple enhancements that drastically reduce the amount of code you have to write for binding data to controls.

SP.NET has considerably raised the bar for Web development with very rich developer functionality built into a flexible and highly extensible object model.

If you have a background of hand-coding ASP or other scripting or CGI-style technology, .NET's redundant code reduction and development process simplification seems almost too good to be true. But data binding for controls leaves a lot to be desired in terms of ease-of-use and reading the data back into the data source. This article examines what's wrong with simple data binding and provides a set of subclasses, making data binding a lot quicker and requiring much less manual code.

Data binding is a task that most developers deal with on a daily basis. Most applications are data-centric and whenever you create UI code that relates to the data, you'll find that, using the default mechanisms of the .NET Framework, you'll do the same things over and over again. Not only that, but .NET really doesn't make data binding as easy as it should be, either in Windows Forms or in ASP.NET. This article describes briefly how data binding in ASP.NET works, and then offers a solution using subclassed controls to handle the repetitive tasks. A future article will discuss the same issues in Windows Forms.

If you're coming from an ASP or other Web development background, you're probably thinking, "What are you talking about?" Data binding in ASP.NET is a huge improvement over whatever you had to do previously in Web Forms. After all, there are forms of data binding and various forms of state management in .NET that automatically assign control values back to the controls, so you're free of manually populating fields with data. That's a big improvement, for sure.

What's Wrong with Data Binding in ASP.NET?
I think data binding in ASP.NET doesn't go nearly far enough. For one thing, the process of assigning data sources is cumbersome, using either a slow and work-intensive designer or by having to embed yet another script-based markup tag (<%# %>) into source code. Both methods 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 goes only one way. You can bind data to controls but there's no mechanism to unbind the data from the control back into its underlying data source. It's hard to really call ASP.NET's mechanism data binding because it is little more than a data display mechanism.

To clarify though, there are two types of data binding in ASP.NET. First, there's the list-based type you use to bind data to a ListBox or a DataGrid. This mechanism actually works very well and provides a good amount of flexibility. It is also primarily a display mechanism—you tend to display data or lists with this type of binding.

You can bind data to controls, but there's no automatic way to unbind it back to the data source.
Then there is simple Control data binding, which binds a single value to a property of a control (such as text box binding to a field of the database). This is also the most common data binding to do during data entry, and the one that is the most time-consuming. Here is where the problem lies: the Control binding is one-way and involves some convoluted syntax that isn't even property-based.

That data binding is one-way in ASP.NET is not all that surprising. It's not easy to automatically bind back in Web applications because it's difficult to tell exactly when data should be bound back to the underlying data source in this stateless environment. After all, on a Web page, a lot of things need to happen in a specific order to re-establish state and there's no easy way to know automatically when a data source is ready to receive the data without some logic as part of the application.

As you'll see in a minute, my implementation skirts this particular issue by having the bind-back operation occur manually through a call to a Helper method or Form method (if using a custom WebForm subclass).

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date