Service Data Objects for PHP

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
thomas777neo
Forum Contributor
Posts: 214
Joined: Mon Mar 10, 2003 6:12 am
Location: Johannesburg,South Africa

Service Data Objects for PHP

Post by thomas777neo »

Hi ppl

Came across this article describing SDO Objects for PHP:

http://www-128.ibm.com/developerworks/o ... w06PHP-SDO

EDIT: Mcgruff is still busy fixing the tag problem, so here is the url without tags:
http://www-128.ibm.com/developerworks/o ... w06PHP-SDO

My question is, does this really give a php coder an upper edge on the design of an application?

I have a pretty jacked "sql on the fly" sort of class, I automatically pick up the table schema, as they call it, and only update the fields to be updated etc. And keep the data persistent as they do anyway, using the session.

So I don't see the point in using SDO at all, it is like using a Templating engine. In my opinion, php is the Templating engine, so why re-invent the wheel?

Your feedback would be much appreciated. Inclined to the advantages of SDO over what Php already has to offer.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

I'll need to read it a second and third time, but on the surface it seems like a verssion of a Data Mapper, but with some extra metadata/automation.

I'm not a big fan of meta-data based methods, but I know some people like them. If the meta data is being carried in the DAO for a paticular object instead of being generic, then its basically what I've been doing for several years -- except I've merged it into the Domain Model (a mistake I hope to remedy some time.... though it does make for easy use in moderate complexity sites)

[edit:
Just read over it some more... I'm definitely not a fan of the XPath usage. This seems to be halfway between a Data Mapper and a Row/Table Gateway, with the disadvantages of both. You have the meta-data complexities of a Data Mapper, you have the implementation complexities of a Data Mapper, and you have the lack of a nice classes/Domain Model of the simpler Gateways. It is a more "generic" solution than either, but not one I'd ever really recommend.... Seems slightly useful for rapid prototyping, but its all to easy for rapid prototypes to get included in production systems..... ]
Post Reply