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 -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
