Data-Driven Programming
An extreme example of dynamic content is found in applications that generate their entire interface using the information in a database record. This approach isn't suited for all types of programs, but it can be a lifesaver in certain data-driven applications, saving you hours of recompiling, and providing other non-programmers with the tools they need to modify and configure your program.Occasionally, a programmer develops a system that allows every aspect of a form to be defined in a database record or XML document. This type of approach is rarely useful because it requires too much code. However, specialized applications might use a scaled down version of these techniques, like a survey-generation tool that allows you to define a collection of forms that represent the questions of a survey. The most common example of all is a pricing application, where the program must match the product catalog as closely as possible. This is the type of application considered in the next section.
A Data-Driven Pricing Application
The next example demonstrates that, contrary to what three-tier design dictates, tight coupling between the user interface and a data source is acceptable sometimes-in fact, it may be the best approach.Consider the case where you have a product catalog that changes frequently. The scope of the changes aren't limited to price; new items and categories are regularly added or removed, and different customers enjoy completely different pricing schemes and discount structures. If you write this application ordinarily, you end up creating a great deal of custom code that needs to be tweaked and changed endlessly as the product catalog changes. Sooner or later, these frequent modifications will introduce unexpected errors or make the program difficult to change or extend (for example, if you decide you need to create a new Web-based version).A more successful way to model this problem is to create a program that constructs its interface according to information in a database. So, when adding a product to an order, the user is presented with a list of categories from a list control, with the description for each also read from the database. When the user chooses items from a category, the whole interface is built out of a grid control (in this case, Microsoft's MSFlexGrid ActiveX control that ships with Visual Studio 6), and text boxes are added dynamically for quantity (see Figure 11-13).

Figure 11-13: The dynamic ordering window
The pricing information is also read from a database. However, the pricing is not product-specific. Instead, every product has a basic price (as listed in the Products table). Additionally, a Pricing table lists different pricing schemes, and gives each one a descriptive name. The Pricing_Products table maps these two tables together, assigning each product multiple prices-one for each pricing system. The database structure is diagrammed in Figure 11-14.

Figure 11-14: Pricing table structure
This application would typically ship with a special admin tool that is little more than a glorified database editor. It would allow the sales department to modify the list of products, change prices, and add new pricing schemes. This system is great for salespeople who love to invent new price structures for every customer.