Mapping objects to tables: the actual database object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey everyone,

I'm investigating using PHP's OOP functionality instead of the
traditional model to implement a project.  I've been looking at
information about mapping objects to tables, and have mostly found what
I needed, but am left with a question I would like to ask here.  If this
is the wrong list for this type of question, please be so kind to
redirect me somewhere else, and please cc me on replies as I do not
subscribe to this list.

When mapping objects to tables, how would one usually handle the actual
database object?  Suppose we have a class Database derived from
PostgresDatabase which implements database functionality (query(),
dataQuery(), numRows(), ...) and then some actual classes:

 SomeClass
     |
     |
SomeSubClass

And SomeSubClass has a MemberClass attribute.  All of these classes need
access to the database to do their work.

SomeClass could just have a Database attribute through which database
operations are conducted, and so SubClass would have it too.  The
trickier part (or maybe I am just thick) seems to be MemberClass.  How
would this class best perform it's database operations?
There are at least two possibilities:

1. Pass MemberClass a Database object when constructing it

The problem with this is that in code that creates just a MemberClass
object there might not be a Database class available.  This could be
eliminated with a factory class perhaps.

2. Make all classes that need database access derive from BaseClass and
   let that class set up access

Has anyone else been down this road?  I'd appreciate feedback on this
issue.

Thanks!

-- 
Alexander Deruwe
AQS-CarControl

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


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux