|
Build More Robust Databinding Apps
Take control of databinding in .NET 2.0 and utilize Visual Studio's new automated testing and refactoring features to make your app more testable and resilient to change.
by Jean-Paul S. Boodhoo
January 2, 2006
Technology Toolbox: C#, SQL Server, ASP.NET
Databinding lies at the heart of many presentation layers in .NET-based applications. It's easy to see why. It's a powerful feature, and many demonstrations of .NET showcase databinding techniques to build data-driven applications. The ease at which Visual Studio .NET allows for the seemingly effortless use of databinding has resulted in a rash of applications that are built using many of the techniques demonstrated in product demos. Unfortunately, many of the techniques and strategies presented at such demos give developers a false sense of confidence about the seeming flexibility of declarative databinding. More often than not, these techniques can lead you down a path that will cause problems as your applications change.
Visual Studio 2005 and ASP.NET 2.0 introduce even more options for taking advantage of databinding in applications, including new data source controls that allow for an even simpler, completely declarative, and in some cases, code-free approach to databinding. These are powerful features, but you must be careful how you use them.
I'll show you how to take advantage of these features to create databinding applications that are resilient to change, that offer compile-time databinding checks, and that you can test and verify without running your application. Along the way, I'll demonstrate and explain how to avoid some of the pitfalls associated with utilizing common approaches to databinding, including issues you run up against when using some of the new data source controls (download the sample code here).
The first decision you must make when choosing to implement databinding in your application is what you'll use as a data source. You have many choices for this in .NET, including data sets, XML, and custom objects.
The more robust example in this article uses a custom object data source, but first I want to contrast this approach with one that uses data sets to illustrate some of the pitfalls you can encounter with that approach. Begin by building a simple Web page that displays a list of information in the Customers table from the Northwind database (see Figure 1).
This example takes advantage of column definitions for the Northwind Customers table, including some of the new controls made available in ASP.NET 2.0—namely, the new data source controls (see Figure 2). Next, configure the SqlDataSource control that drives the page (see Listing 1).
This approach looks great on the surface. In less than two minutes, you can have a fully data-driven Web page, with no code required, by relying completely on ASP.NET markup tags. You can use Visual Studio to manipulate the SQLDataSource control, and it can generate the ASPX markup for the control configuration. This results in a completely wizard-driven approach to databinding.
How Codeless Comes Up Short
Unfortunately, this approach has some issues. First, using the SqlDataSource control requires that the view (page) have intimate knowledge of the database. The view determines where to pull the data from, as well as how to display that data. If the connection string were stored anywhere other than the configuration file, the view would also be responsible for providing a connection string to connect to the database. This is simply not a good way to separate the responsibility for various aspects of your app.
Another, more significant issue: You must run the application to verify that the databinding works. For example, assume you change the name of the "Customers" table to "Customer." You might think you can make this simple change, rebuild the database, and be ready to roll. But running your application at this point will generate a server error indicating that Customers is an invalid object name.
This is a common scenario for many developers. One small change can cause ripple effects that go unnoticed until you attempt to run the application. This approach can slow down the development process and reduce confidence in the application's functionality. This architecture is fundamentally a two-tier approach, and it limits the flexibility of your app.
Back to top
|