The DB Access Modules contain the derived, database-dependent variants of the implementation classes. You don’t even have to think about these classes; you deal only with the portable semantics defined by the DB Interface Module. It is the responsibility of this module to provide your application with the correct variant. The DB Interface Module does this by using what is called the Producer/Product paradigm, which is sometimes referred to as the factory or kit approach.

Under the Producer/Product paradigm, an application obtains object instances (Products) by requesting them from other object instances (Producers), rather than by invoking a constructor. Using this paradigm, the DB Interface Module ensures that all objects with database-dependent variants are correctly typed. An Oracle RWDBDatabase can only produce Oracle RWDBTables; a Sybase RWDBTable can only produce Sybase RWDBReaders, and so on.

By convention, the name of the method that a producer uses to produce a product is the name of the product minus the RWDB prefix. In the following example, an RWDBReader is obtained from an RWDBTable, which was obtained from an RWDBDatabase, which was obtained from the RWDBManager:

Class RWDBManager is at the root of the tree of object producers. An application specifies a database type to the RWDBManager by including the name of an Access Module, as well as other information necessary for establishing a database session. The RWDBManager negotiates with the named Access Module in order to produce a correctly typed RWDBDatabase instance. Notice the call to RWDBManager::database(). From this point on, database details are no longer visible. The RWDBTable and RWDBReader instances in the example above are guaranteed to have the same database-dependent implementations as the objects that produced them. The arguments required to open a database connection are specified in the Databases and Connections sections in the Access Module guides.

Table 2 shows the Producer/Product relationship among the database-dependent classes of the DB Interface Module. An indented class is produced by the previous less-indented class. At the root of the tree, class RWDBManager is responsible for producing database-dependent RWDBDatabase instances. Classes produced by RWDBDatabase are indented one level below RWDBDatabase, and so on.

Some class names appear more than once in the figure. This is because certain classes have more than one producer. For example, to read an RWDBTable, you request an RWDBReader from the RWDBTable you want to read; to read the results of a SELECT statement, you request an RWDBReader from an RWDBSelector.