|
|
|
| Motivation | Although most object-oriented databases
provide very similar functionnalities, and although the ODMG has
delivered a standard for
storing objects, the API provided by different databases are still
different. As a consequence, it is not straightforward to write
applications that are portable from a database to another.
However, some programming methods can help a lot, especially the ones described in the book by Gamma et al. : Design Patterns. To design an application which aims at being independant of a particular database vendor, Bridge and Factory are the key patterns. The basic idea is to separate the IO processing from the rest of the activity carried out by an object. The dialog with the database takes place in an associated object, a kind of peer, thus decoupling the database dependant and independant parts. The object in charge of the relations with the database manages the data. It has as many implementations as different databases are supported. |
| Example | To test this approach, a small example has been developped. The
inspiration came from a paper by Johan Wikman from Nokia which
describes his solution in the C++ language to the problem of database
portability.
The example is centered on a small object consisting of a few fields, extended from a base object and connected to another one. A container stores a collection of these objects. The collection is made persistent within a database which can be one of Objectivity, Versant or ObjectStore. A simple ascii flat files option has been also implemented. And now a version based on serialized objects is available as well. To go further a new version based on Corba has been developped. This more powerful application is presented in the NBDMS page. |
| Advantage | The advantages of such a design are the
following :
The application can work with any of the avalaible databases. Providing that the adaptating objects are written, the portability is guaranteed. The link to the vendor package is dynamic. The vendor can be selected are runtime. It is possible to change the database provider during the life time of a program, an application can be attached to different databases on different sites. Performances, architectures, costs of various products can be compared easily. New vendor implementations can bee added without too much efforts. |
| Disadvantage | However, the functionnality provided by
this approach has a cost :
The implementation of the bridge needs a large number of lines of
code. There is a difference between the elegant description in the
Gamma's book with the nice small UML diagrams and the real files and
classes with the hundred of boring A special kind of objects is needed : the persistent class. Objects belonging to this class are in charge of transferring data to the peer objects handled themselves by the database mechanism. As a consequence, the business objects cannot be made persistent without explicit modifications. |
|
|