On Tue, 2003-10-14 at 19:51, Chris W. Parker wrote:
> Hey peeps.
> 
> Let me try to make this simple. Right now I have a base db class that is
> moved solely for interacting with the db. It opens the connection, runs
> queries, and returns the results of those queries. Along with this class
> I've got some other classes (I'll call them "upper" classes) that are
> used to interact with different aspects of my project. For example I've
> got a Products class (used to add/delete products, etc.) and a Category
> class (used to add/delete categories, etc.).
> 
> Currently I'm extending the base db class into these "upper" classes.
> i.e.
> 
> class DB
> {
>       function dostuff ()
>       {
>       }
> }
> 
> class Products extends DB
> {
>       function dothings ()
>       {
>               $this->dostuff();
>       }
> }
> 
> On this list I read a post that suggested I not do it this way but
> instead instantiate a DB object within each method of the "upper" class
> whenever necessary (as far as I understood the recommendation).
> 
> This sounds like a good idea except that this would mean I'd be creating
> and destroying a DB object each time a method in an "upper" class needed
> to access the db. The way I'm doing it now requires that I only
> instantiate one object for the entire page and let any method in that
> "upper" class to share the connection.
> 
> With my limited knowledge of OOP the only solution I can see would be to
> use a constructor in the "upper" class to instantiate the object when
> the "upper" class object is instantiated.
> 
> Am I making sense and does anyone have any suggestions or comments to
> add? Maybe something to straighten me out?

It's not so much "don't do it" as much as it is a case of you'll
probably run into problems later if your application gets much bigger.
By extending the database class you tightly couple your product class
with that of the database class. That can be ok, but in the case of
products, are they really that related to your database? As you say
instantiating an instance of the database connection everytime you want
to make a query is probably not a good solution either, although it
ensures that you get a clean connection and that your product class is
not dependent on the DB class. To overcome this issue your DB class can
implement some kind of pooling system. In other words for any given
request for a connection, you can see if a connection was created
previously and if so, and if freed return it. Otherwise if none are free
then you create a new connection, add it to the pool, then return it.
generally speaking you'll find that very few actual connections are made
using a pool like this.

HTH,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to