Rationale
(For those who don't care, click here to skip to the details ;))
Like many of the pre-PEAR PHP frameworks out there, the Sitellite
Application Framework (SAF) sports its own database abstraction layer.
While we've considered migrating to PEAR::DB or to ADOdb, and most
promisingly to the MDB package, there are always obstacles to doing
that which for us outweigh the benefits. For example:
- Existing code breaks. While another layer of abstraction could
solve this to an extent, it would just add one more level of code. And
it's not like the existing code was something that only executes
occasionally, it's Sitellite itself. We even thought about
doing a code update, but looking through Sitellite you'll quickly
realize the size of the undertaking that would be. This leads us to the
next point:
- If it ain't broke, don't fix it. Despite what the industry "best
practice" is, which would be to replace old standards with new ones the
minute a drought appears on the horizon, a sweeping change from one
"standard" to another (in this case saf.Database to another database
abstraction layer) can often introduce more bugs that weren't there
before. While it has the potential to reduce bugs as well, this
potential is rather low because such an update would be concerned with
the form of the code, and not its function.
- Artistic differences. Sitellite's database abstraction layer has deliberately taken a step back from where the others have gone. That is, instead of making it more
object oriented, we've made it more PHP-like. We've done this by
creating convenience functions that alias all the methods of a global
Database object ($db), which despite what the OOP camp will tell you does significantly increase the readability of your database-accessing code. However, notice that we called these aliases.
The underlying API itself is fully object oriented, and so you can also
exploit the benefits that that offers to different circumstances
(inheritance, etc.).
- Is there really a standard abstraction layer in PHP? I'm sure we'd
all like there to be, since it would have saved us all a lot of time
developing the dozen or so APIs that now exist. But there isn't one,
and so a choice exists.
- SAF is PEAR-compatible anyway. So if anyone really wants to use
PEAR::DB, or MDB, they are perfectly free to do so within Sitellite
(just call `loader_import ('pear.DB')`). Choice can be good, and we've
made that possible. So technically, with Sitellite/SAF, you get the
best of both worlds: choice.
The only con to the whole deal is that a dedicated database
abstraction layer project can focus more developers on a single area of
functionality than a larger framework can. However, relational
databases aren't a technology that changes very often, and so the
concept and generally accepted standard structure of a database
abstraction layer hasn't changed very much in I don't know, around ten
years at least. To be honest though, SAF does still lack in one area:
Drivers. Since MySQL has become so ubiquitous (especially in
combination with PHP) that many customers are very happy with it as
their sole web database, the MySQL driver has gotten far more testing
than the others. However, I shall remind you, good reader, that
Sitellite is an Open Source project, and as such is always looking for
contributors to help make the softer spots callous over (so to speak).
This encourages us Open Source projects to admit our weaknesses as
well, which is necessary to overcoming them.
Page 1: Rationale
Page 2: A Simple Example
Page 3: Model-View-Controller (MVC) Mistakes
All Tutorials
