This paper shows one way to handle object-relational mapping. The technique has much to recommend it:
Business classes can be changed without disturbing each other.
New classes can be added without requiring changes in existing code.
Data storage methods in business classes (like Hippo::load()) are easy to write.
Application utility tasks (checking permissions, logging, etc.) are centralized for easier management.
The RDB retains its natural structure, so it can be used easily with query generators, data miners, etc.
The BusinessBase class is general. Developers can use the same class in many different applications.
The code above is simplified, of course, to focus on the object-relational problem. The code
doesn't check for errors, like bad database connections, or repeated field names
(e. g., ArmedHippo defining a field that Hippo
has already defined). Application utility tasks haven't been fully specified. Collection classes
(e. g., HippoHerd) haven't been discussed. Compound primary keys are not handled. A database
abstraction layer (e. g., ADODB) should be used. Parameters like database user name and password
should not be hard-coded. And so on.
However, all of these problems can be addressed within the architecture outlined here.
BusinessBase::save() could check for errors, log database changes,
use an RDB abstraction layer, and so on. Adding these things to BusinessBase
would yield a robust, capable, reusable class that simplifies business application development.