A couple of good replies have been posted. Before I address them, let me start by saying that this article is meant to be an introduction to the concepts and design patterns related to DataObjects. I chose very simple examples of how to implement DataObjects in PHP. It'a also meant to help demonstrate how DataObjects can make working with a database more transparent. The hope is to, at the very least, get the novice PHP coder to think about how they interact with their database.
In response to Tony, I also use an abstract DataObject super class in my applications. It takes care of the basics: select, insert, update, delete. I didn't use this super class in my article, as I felt it would complicate the topic too much for the novice (although I did mention writing one in the last paragraphs). I spent some time reading over your site as well. It seems we hold many of the same views on many topics. It's nice to see someone else using XSLT for their presentation layer,
In response to EViL3, you're right, In your words: "...this is an old idea being re-hashed for a new generation." I've found that a large number of PHP coders out there (from the novice to some veterans) generally hard code queries, often repeating common DB tasks. The intention here is to get folks thinking about how best to represent data from a relational database as PHP code. Once the DataObjects are created, the coder can interact with the DB using only PHP code, not SQL. As I stated in the article, there are many ways to implement DataObjects. This article purposefully presents them in a very simplistic manner. The "how" is not as important as the "why" in this case. For a simple solution to joins, I tend to use read-only view DataObjects (I have an abstract ViewDataObject super class I regularly use).
I took some time to read about SQLMaps. And yeah, they do look interesting. Pear:DB_DataObject tries to do this (in a manner of speaking), but they chose not to use XML... an odd descision if you ask me.
Thanks for the comments.