I remember a post by its author where he stated that PHPLIB::DB was never designed as an abstraction layer but rather as a wrapper around
And now we are at the point of different definitions of an
abstraction layer. I see it as a "lightweight" abstraction
layer, fast, KISS and not fat.
I think a component system might be nice -- have light uniform API
classes and then additional components / tools to handle the real
abstraction stuff. Kinda like MDB currently breaks out the "Manager"
classes. I think it would also make sense to break out the metadata
classes. Personally I really like the JDBC model, and myself have been
doing some work on a JDBC-like Uniform API for PHP5/ZE2 (some prelim
info at
http://creole.ws).
There are also a lot of convenience functions that maybe really don't
need to be in the core uniform API class. Things like getOne(),
getAll(), etc. (which I myself use quite frequently) should maybe be in
an optional component -- so that the core classes can be kept smaller.
ADOdb is very efficient primarily because abstraction is kept to a
minimum -- i.e. the adodb methods called immediately call the native PHP
function (e.g. $rs->MoveNext() calls mysql_fetch_array() immediately);
this isn't the case (IIRC) w/ the DB:: or MDB:: methods used by the
[ADOdb] benchmarks. More generally, I simply think that ADOdb is a
demonstration of the performance vs. architecture quality trade-off.
Cheers,
Hans