Many of the ASP.NET controls you work with to develop web pages support data binding. For example, when you use a DropDownList or GridView control, you can explicitly supply the data to display through code you provide, or you can specify that the control is to "data bind" to a data set, in which case the control automatically retrieves and display data.

Although it is convenient to use data binding, it becomes increasingly difficult to manage a web application in which lots of web forms use lots of data-binding controls. That is because most data binding is usually done directly to a database, resulting in the creation of multiple data sources, with multiple connection strings and one-off SQL statements.

The alternative of explicitly taking control of database access within the code-behind files and moving data into controls via code that you write, is tedious. For each control, you need to become familiar with how to manipulate data within the control and provide code to work with the results returned from the database.

Try This

Another technique that provides the ease of automatic data binding but lets you retain more control over the actual database operations is to use an object data source, which is nothing more than a reference to code that you provide. When you develop an ASP.NET web form with controls that support data binding, you link the controls to your code, identifying the methods within your code that you call to support select, insert, update, and delete operations.

Within your object data source code, you can perform whatever operations are required. You can run SQL statements or retrieve data from other sources, for example, via web services calls. Because the object data source code that you develop is in a separate class, you can test and debug that class independently of the ASP.NET web form. Using this technique lets you separate responsibilities when developing websites.

For example, you may work on a team in which some people are really good at developing web forms but not so good at database work. Rather than force web developers to get up-to-speed with database best practices, you can take control of the database access and provide code that they call. Because the object data source supports data binding, it is in fact simpler to develop web forms using object data sources than trying to create unique connections and SQL statements for each control used on a form.

An Example Application

To help you see how this might work out, look at Figure 1, which is a Visual Basic class named ObjectDataHandler.DataHandler. The class contains one function named GetCustomer that takes an integer parameter of the customer number to retrieve. The function runs a simple SQL SELECT statement to retrieve the customer and returns the resulting row of data in a DataSet object. The class uses the IBM DB2 .NET Provider for the i. It would be just as easy to use the IBM OLE DB Provider or to switch to any other database provider. For simplicity, the SQL statement and connection string are "hard coded" in the example. Also, there is no provision made for handling an invalid customer number.

As you see in Figure 1, the code is trivial. After opening the connection, the function creates a iDB2DataAdpater object and a DataSet object. The data adapter runs the SQL statement, which fills the data set. The data set goes back to the caller.

Testing

To test the application, you can use the DataHandlerTester shown in Figure 2. This short program simulates what happens when you invoke the code in the DataHandler class at runtime from a web form. As you can see in DataHandlerTester, the program creates an object named dh based on the DataHandler and invokes its GetCustomer method. The console displays the DataSet object that is returned by simply iterating through all the data returned for the single row of customer data retrieved.

Now that the DataHandler class is available, you can use it with an ASP.NET web application. When you go into the web application in Visual Studio, you need to add a reference to the DLL that contains the DataHandler class.

Figure 3 shows the DetailsView control in the Visual Studio Toolbox and on the web form. You set the data source that is bound to the DetailsView by accessing the DetailsView Tasks menu, shown in Figure 4. When you select the option, a "wizard" launches to guide you through the selection and configuration of the data source.

Figure 5, Figure 6, Figure 7, and Figure 8 show the sequence of panels in the wizard. On Figure 5, you select the Object type; the ID for the data source generates automatically. You can accept the ID or change it. When you click OK, the Figure 6 panel displays itself. Assuming that you have added the reference to the DataHandler DLL to your ASP.NET web project, you can select the DataHandler object using the drop-down list.

Figure 7 shows how you specify the method within the object data source to correspond to an SQL SELECT request. If you have multiple methods in the object data source, you can select the method using the drop-down list. Figure 8 shows how you pass parameter information from the web application to the object data source. In this example, the QueryString, which is part of the URL used to load the web form, supplies one parameter (cusnum).

After configuring the object data source, you can run the web application. When the web form loads, there is no cusnum query string parameter, so the initial web page displayed is blank. You can add the ?cusnum= query string to the URL, as shown in Figure 9. Once you’ve added the request string parameter, the DetailsView control calls into the object data source, sending the cusnum parameter value. The code in the DataHandler runs and returns the DataSet back to the DetailsView. The DetailsView then displays the column names and the data, as shown in Figure 9.

Obviously, Figure 9 is a rough-cut starting point for a web application; it will benefit from a web designer's talents. However, you don't have any code in the code-behind file for the web application. All the work performed on the web form is simply done by the combination of the DetailsView and the object data source.

To Bind or Not to Bind

I must confess that I have very little enthusiasm for using data binding when done directly on the controls. However, I am very much in favor of data binding when I am can use the object data source technique. For something as important as access to a database, I want to see the code and be able to work with it independently of the web page. I am perfectly happy to use data binding as long as I have the greater control over the process that I’ve described in this article.