One of the problems with so-called “generic” PHP libraries is that they frequently contain dependencies that are either in conflict with an application, or that require a large amount of duplicate code.
This really shows up in database interfaces. If the library needs to manage persistent data, then there’s going to be a database interface. There are a lot of packages out there that aim to ease the challenges of interfacing to various SQL databases. Being a fan of PEAR, I tend to use MDB2. Others use ADODB. Application frameworks such as Joomla provide their own.
These interfaces only address dealing with SQL databases, but that in itself is a little archaic. What about web services, where the specific implementation of the persistent store is hidden? What about XML based databases using XPATH?
My ACL module attempts to deal with this by completely decoupling the persistent data store from the application. An abstract Data Store class provides methods to create, fetch, and update objects, as well as some specific methods to implement operations that are best implemented with more complex queries, such as one to fetch all permissions related to a set of requesters and assets (in the ACL module a requester is something asking for permission to access an asset).
This means that the core ACL doesn’t have even the slightest hint of SQL in it, and that’s a good thing. There’s something very clean about making the interface to persistent data explicit, clean, and well defined.
Something very interesting happened as a result of organizing things this way. The data store implementation rapidly starts to show similarities with Java Enterprise Beans. There’s little tables that map class properties to database columns, and helper methods that transform the data from the object’s model to the database’s model. This is a little scary, because I’ve seen and heard a wealth of horror stories related to the effort required to configure Enterprise Java applications, and I’m really hesitant to bring those problems into something intended to be quick and easy to implement.
On the other hand, the MDB2 data store wasn’t all that difficult. Next week, after the Joomla bug squashing day, I’ll tackle a data store that’s native to the Joomla framework. I’m pretty sure that will go fairly smoothly. If it does, I’ll have a lot more confidence that the architecture was worth the investment.
Recent Comments