"Paul M Foster" <pa...@quillandmouse.com> wrote in message 
> On Sun, Jul 19, 2009 at 03:56:43PM +0100, Tony Marston wrote:
>> Two things strike me as wrong with your thinking:
>> (1) The idea that you have a separate DAO for each entity instead of a
>> single generic DAO which can act for any entity in the system.
>> (2) The idea that pagination requires its own class, and therefore needs
>> this "is-a" and "has-a" nonsense.
>> As for (1) even in my pre-OO days I was used to using a single generic 
>> DAO
>> for all database access. The only time that more than one DAO existed was
>> for a different DBMS engine. This is why I have one DAO class for MySQL, 
>> one
>> for PostgreSQL and another for Oracle. If you are incapable of writing a
>> single generic DAO then it just shows that you still have a lot to learn.
>> For an idea on how this works take a look at
>> http://www.tonymarston.net/php-mysql/databaseobjects.html
> This brings up a question. Most of the tutorials I've read on your site
> deal with classes tailored to specific tables. However, in much of my
> software, I have to deal with queries which access multiple tables. For
> example, my invoice table contains the customer number, but not their
> name. For that, I have to go to the customer table. Thus, my queries
> often access multiple tables with where clauses which ensure I get the
> proper data from secondary tables. I've never used "views" in SQL, but
> it appears that this is what would be called a "view".
> So in your constellation of software, would you create a subclass of
> genericTable which essentially is a "view"? Otherwise, how would you
> handle this?
> Paul

Such things can be handled automatically by my generic DAO. Amongst the 
details which are exported from my data dictionary into each table structure 
file (which is accessed by the database table class) is a list of all the 
parent/foreign tables, the foreign key field(s), and which fields to 
retrieve from the parent table. So when the sql SELECT statement is being 
constructed it can use this information to add a JOIN to the parent table in 
order to retrieve the specified field(s). This is documented in 

Any number of parent relations can be defined for a table, and any number of 
fields can be retrieved from those tables and added to the SELECT list. All 
the developer has to do is define the relationship in the data dictionary 
and the framework will handle the boring stuff of generating the necessary 

So, using your example, I would define my customer table as a parent to my 
invoice table, identify which foreign key field relates to which primary key 
field in the parent table, define customer_name as the field to be retrieved 
from the customer table, then sit back and watch the framework do its stuff. 
Each time I read from the invoice table the result would automatically 
include the customer name.

Easy peasy lemon squeezy. It's not rocket science, but it is neat.

Tony Marston

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

Reply via email to