With the advent of ASP.NET, and Visual Studio.NET with its graphical tools to provide design-time databinding support, the concept of databinding has really come of age. Databinding to ADO.NET
DataTables is a well accepted and well documented technique. However, there is a school of thought that considers
DataSets to be ugly, cumbersome and just not compatible with an object oriented approach. A discussion of this point of view is beyond the scope of this article, however, an interesting debate about this can be found here. In this article, we will simply deal with how to bind objects to web forms.
Fortunately for developers who prefer to work with objects rather than
DataSets, Visual Studio provides good design time support to bind controls to objects, although this approach is not particularly well documented. Databinding to objects is very similar to databinding to
DataSets, except that object collections and properties are used in place of
DataTables and fields. Following is a walkthrough creating a simple web project that creates a very simple
Person object and binds it to a web form. The project and source code are available for download.
Model View Controller
The approach used here follows model view controller architecture. They are presented here as model, controller, view, simply because this is the logical order in which to discuss them.
Model (the business object)
I will not discuss the business object in detail as it is simply a very simple class,
Person. There is nothing noteworthy about it, it exists purely to demonstrate the concept of object databinding. It contains the following properties:
So far we have a business object (
Person) and we can, of course, create a web form. But how do we get the object ‘onto’ the form so we can bind to it? One way of doing this is to create a middle tier object that can ‘hold’ our
Person object and that supports databinding. For those who are familiar with 'Model View Controller' architecture, this component represents the controller in this architecture. To create a class that can both contain our object and that we can place on our web form at design-time, we create a class that inherits from
System.ComponentModel.Component. I have called this class a person adapter simply because that is the convention we used in my last project.
public class PersonAdapter : System.ComponentModel.Component
private Person person;
public Person Person
The adapter is the logical place to put presentation code. In our example, we want to make the back color of one of our controls match the person’s favorite color. The
TextBox server control has a
BackColor property that can be bound to any property of type
System.Drawing.Color. Thus we create this property in our
public System.Drawing.Color FavoriteColor
Once this component is compiled, it can be placed on our toolbar in the standard manner, by right-clicking on the toolbox and selecting ‘Add/Remove Items’. Once placed on the form, the component appears in the web forms design tray:
View (our webform)
To databind to our new
PersonAdapter, we must create a new web form. Note that we can turn ‘viewstate’ off – our databinding will take care of making sure our control's text stays constant between browser refreshes.
We are now ready to bind our desired control properties. Note that ASP.NET supports binding a large number of control properties, not just text. The example form has many properties bound, we will take only one as an example. Say, we want a text box on our form with the backcolor set to the favorite color selected by the user. To do this, we select the text box we want to bind and click the ‘Databindings’ builder:
This brings up the databindings dialog box. To bind, we simply click on the control property we want to bind,
BackColor, and bind it to the
Color property of the Adapter’s
Putting it all together
There is one final step before we can make this form ‘go’. We must tell the web form to activate databinding. This is done by calling a single method:
I have added some rudimentary editing capabilities into our
Person object, so the entire code in our aspx page is thus:
private void Page_Load(object sender, System.EventArgs e)
That’s literally all the client-side code required.
In my (biased) opinion, this is an elegant solution to many standard business data-centric web based projects that could scale to any degree of complexity. The business logic is in the business logic classes, the presentation logic is in the controllers (adapters), the web form binds to the presentation logic, and the web forms themselves don’t contain much code at all. The object oriented nature of this solution makes its code easy to read, easy to maintain, and quite flexible.
Depending on interest levels and my time, this approach could be extended:
The upcoming .NET 2.0 / Visual Studio 2005 will feature
ObjectSpaces, an object / relational mapping system. This will allow developers to work with
ObjectSets as opposed to
ObjectSets will apparently support databinding to web controls as well. However, you may still choose to use the concept of controller objects (adapters) to abstract away the presentation logic. The point is that Microsoft is committed to providing design time tools for the object oriented programmer, so using the techniques I have outlined here will stand you in good stead for the next generation of MS products.
The data binding presented here is one way only. Data is passed from the object to the form. When the user submits the form, we just use the POSTed values to update the object. Two way databinding would pass the updated object back from the client to the server. This may be able to be achieved by the use of viewstate and/or serialization.
Add a database
Code to persist the object to a database, rather than just in memory, could be integrated. The SQL would be embedded into the business logic itself. The approximately 8 million Data Abstraction Layer methods discussed in CodeProject articles do not fit well within an object oriented architecture, I believe.
But that’s another discussion…