A Practical Approach to Object-Relational Mapping in PHP Page 10

You can download all of the sample code here.

Conclusion

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.