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 M. Foster

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

Reply via email to