Thread: Php abstraction layers

Php abstraction layers

From
"Antimon"
Date:
Hi,
I'm working on a new web project based on php and i decided to use
PostgreSQL 8.x as
dbms. For triggers, views, stored procedures etc. I was going to write
a simple wrapper class and use pg_* functions. But some friends adviced
me to use an abstraction layer. I checked PEAR:DB and AdoDB. They look
pretty but i don't understand why sould i need one? Project will be
postgre dependant because of the database structure, i don'T need to
support multiple dbms types. Since i may not even have a chance to
convert database structure. And php 5.1's postgresql library has all
new
features implemented.
In this situation, what would be the advantage of using an abstraction
layer?
Thanks.


Re: Php abstraction layers

From
Chris Travers
Date:
Antimon wrote:

>Hi,
>I'm working on a new web project based on php and i decided to use
>PostgreSQL 8.x as
>dbms. For triggers, views, stored procedures etc. I was going to write
>a simple wrapper class and use pg_* functions. But some friends adviced
>me to use an abstraction layer. I checked PEAR:DB and AdoDB. They look
>pretty but i don't understand why sould i need one?
>
Do yourself a favor and write lightweight wrapper functions.  This means
that if something needs to be changed (say, a PHP API name change
happens) you don't have to rewrite a lot of your code.  Additionally, if
you do have to port someday to Interbase or even (gasp) MySQL, it
becomes possible thought not always straightforward.
  *Simple* and light database abstractions are very nice because they
isolate your framework from the API syntax and after a few years,
something could change and then you don't have to rewrite a whole lot.

Best Wishes,
Chris Travers
Metatron Technology Consulting

Re: Php abstraction layers

From
Guy Fraser
Date:
On Tue, 2005-30-08 at 21:00 -0700, Chris Travers wrote:
> Antimon wrote:
>
> >Hi,
> >I'm working on a new web project based on php and i decided to use
> >PostgreSQL 8.x as
> >dbms. For triggers, views, stored procedures etc. I was going to write
> >a simple wrapper class and use pg_* functions. But some friends adviced
> >me to use an abstraction layer. I checked PEAR:DB and AdoDB. They look
> >pretty but i don't understand why sould i need one?
> >
> Do yourself a favor and write lightweight wrapper functions.  This means
> that if something needs to be changed (say, a PHP API name change
> happens) you don't have to rewrite a lot of your code.  Additionally, if
> you do have to port someday to Interbase or even (gasp) MySQL, it
> becomes possible thought not always straightforward.
>   *Simple* and light database abstractions are very nice because they
> isolate your framework from the API syntax and after a few years,
> something could change and then you don't have to rewrite a whole lot.
>
I would have to agree with this.

As a network administrator I work with IP and MAC addresses alot,
so I can use the extensive support for them as leverage when
choosing a database for a project. That being said, I have other
people to please and sometimes they get their way and I have to
use MySQL. I do not to use PEAR or CPAN modules because I haven't
had the time to learn their API's and don't know how secure they
are.

As Chris suggests, I write wrapper functions to create and
maintain one or more connections to the database as well as
functions for inserting, updating, deleting and making
different kinds of selections from the database. I have found
it handy to store status, error and data in an array of
associative arrays for each transaction with the database. The
trick to making the code compatible is how and where the error
and status data is stored. The PostgreSQL pg_ functions return
quite different error and status information than the MySQL
functions.

Another trick is to write wrapper functions that take a
"driver" option to determine which "library" to use. Since the
same array format is returned from either "library" the rest of
the code doesn't need to know anything about the database.

One thing to take care with is ; making sure you escape any
filter anything put into a database command to ensure that
you don't create SQL injection vulnerabilities.



Re: Php abstraction layers

From
"Antimon"
Date:
I wrote a wrapper class based on pg_ functions. Added some logging and
exception throwing capabilities etc.
I'm planning to use only prepared statements and pg_query_params
function when using user submitted data in queries to avoid
sql-injection. I believe it is enough but gonna do some tests.
This is the best way i think.

Thanks to everyone.