An application's business-services tier generally maintains a separation between business logic and data access components. For instance, the Island Hopper example has separate components for Accounting and Classifieds. Each component defines methods for bus_CustomerC and db_CustomerC with associated parameters. Although this approach gives you flexibility to change your data storage engine without affecting your application, it does not promote the reuse of objects outside the application for which you originally designed them.
You can reuse the components in this release of the BDG in a variety of scenarios. SQLXML is a good example of a reusable component, because it makes no assumptions about the logical meaning of the data it manipulates. The same is true of postIt.asp. Because the parameters of the stored procedures are dynamically discovered, the interaction between the component and the database is very generic, which allows you to reuse the component in many situations.
If you make reusability a high priority in the design of your application, you will build components that treat all data as equal. There are other reasons to follow the "traditional" design model, however. If you are designing an application with temporary storage and plan to change the underlying data engine at some point, it makes sense to limit the impact of a database change to a few COM objects.
This approach contrasts with the Windows DNA approach to data access components that wraps database calls within custom Visual Basic code. The component written for the PT application is easier to reuse because it treats all data as equal. Also, because the component relies on the database to report errors, it achieves stricter adherence to data integrity rules. The downside of this is decreased flexibility when you choose the underlying data representation, because you may need to rewrite stored procedures.
A side effect of this approach is that the field names in the database must be promulgated everywhere, from tables to stored procedures to data-bound HTML and client-side script. This "natural" field-naming technique (where the names of the data elements serve as the convention for the remainder of the application) makes it easy to discover where specific data belongs, but makes it harder to track down all the places in the application that need to be changed when field names in the database change.