Best Practices: Database Abstraction Page 5

Conclusion

We’ve seen that PEAR is functional as a database abstraction layer, but is it
a good database abstraction layer ?

Let’s take a look at some properties of a good abstraction and see how PEAR fares:

properly named

The first thing you encounter in an abstracted object is it’s name, and you
know what they say about first impressions.

makes sense

The properties and methods that make up the object should be appropriate for that object.

minimal

Introducing extraneous properties and methods only serve to complicate the
object and your use thereof.

complete

The object must contain those properties and methods that are required to
use the object for the purpose for which it was designed. A database object
that lacks some fundamental database functionality is useless.

All code that is submitted to PEAR adheres to the coding standards that have
been agreed on by the core programmers in the group. Often, a lot of
discussion surrounds the naming and contents of classes that are submitted to
PEAR, so peer review takes care of points one and two.

The last two points can be debated long into the night. Some will argue that
making everything an object is not always necessary, while others will see this
as is necessary for a complete database object. What is certainly true is that
wherever it has been possible to include functionality without breaking the abstraction
API for other database types, it has.

The STATUS file in the PEAR cvs contains an updated list of the DB classes, what they are capable of and how the support is implemented.

Even though the PEAR DB code is not without it’s bugs, development is ongoing.
Hopefully this article has given you an idea of what is possible and a taste of things to come.

— Allan

 

More information:

• PEAR article on PHPBuilder
  .
• PEAR coding standards
  .
• PHPDoc PEAR documentation
  .
• Free Online Dictionary of Computing.