Why Use a Data Module?

For a simple system, and especially when you are just starting with C++Builder, it is sufficient to place nonvisual components, such as timers, queries, and data sources, right on the form. But this clutters the form with components, and, as the system grows, it is more difficult to manage these nonvisual components so that they stay out of the way of the visual components . Data modules enable you to group those components outside the user interface form, in a central location of their own.

In addition, you will notice as you develop new applications around a specific database that you have to duplicate nonvisual database components in each separate application. This fails to take advantage of the ability to reuse, which is such an important feature of object-oriented programming.

Data modules, on the other hand, can be shared with multiple projects, either directly, or through inheritance from the Object Repository; thus, your database logic implementations can be easily reused to provide consistency across applications. Indeed, the same data module can be used in a form application, a DLL, a COM object, a CORBA object, or a Web application, making data modules the ideal home for core program logic.

You might find a need to use databases that are similar to each other, where one database extends another in important ways. When you use data modules, you can use form inheritance to create a data module for the basic features of the database, and then create an extended data module that inherits from the ancestor data module, but adds components, handlers, fields, and extends event handlers from the base data module.

Data modules also offer the ability to encapsulate validation and referential integrity logic outside the database ”which can be a good idea even when a DBMS does offer referential integrity support because it offers an extra layer of protection.

And, when used with MIDAS, a special form of data module ”the Remote Data Module (RDM) ”enables you to use data modules as one or more middle-tiers in a multitier distributed database system.

Finally, data modules can reflect your database design. If you use Entity-Relationship style modeling or similar methods , each data module can be an entity from the diagram. For example, the Order data module in Figure 7.1 (which represents an Order entity) contains a table for the orders (called simply Table ), a product table (called Product ) for all the valid products that can be associated with an order, and a status table (called Status ) for all of the valid status values an order can have.

Figure 7.1. An `Order` data module.

graphics/07fig01.gif

You can, of course, have as many data modules as you have entities, and you can link the tables within or across data modules in master/detail or other relationships ”even regardless of differences in underlying DBMS.

This style of data module development allows for easily read notation, such as

 OrderStatus = Order->Table->FieldByName("Status")->AsString;

and also makes it easy to reuse consistent names , as in the following:

 OrderStatus = Order->Table->FieldByName("Status")->AsString;  AccountStatus = AccountStatus ->Table->FieldByName("Status")->AsString;

Top

Figure 7.1. An Order data module.

Figure 7.1. An `Order` data module.