xPDO and PHP Object Generator

Anychance of a few quick insights into the distinction between xPDO and POG http://www.phpobjectgenerator.com/? (aside from the XML capabilities).

Really just trying to learn more about ORM/ORB and figure out whey xPDO is the best solution (over and above generating my own data access layer for individual projects for example).

Cheers,

DM

Quote from: DangerMouse1981 at Jan 13, 2008, 11:03 PM

Anychance of a few quick insights into the distinction between xPDO and POG http://www.phpobjectgenerator.com/? (aside from the XML capabilities).

They both strive to help you get started with coding application logic more quickly by creating a common set of CRUD methods for working with table rows from a relational database table (i.e. object = table row). They both work in PHP 4/5 and support PDO, but, their architecture and concept is completely different. Whereas POG generates independent, stand-alone classes with everything needed, xPDO allows you to extend a powerful set of base classes (or provide your own custom ones) that define CRUD behavior, related object behavior, etc. The XML schema allows for quick reverse and forward-engineering of the tables/classes/maps, and the features of the xPDO class itself enable additional behavior (i.e. finder methods, result-set caching, etc.) for working with PDO and a set of related classes/tables as a single, robust domain model.

xPDO requires PDO, as it depends on many of the concepts it introduces, though it provides it’s own PDO-subset emulation layer for PHP 4 or PHP 5 without PDO or the proper driver.

Thanks OpenGeek for the insightful reply.

I’m not much of a PHP coder as yet, but have recently spent alot of time researching design patterns and the like in a bid to adopt true OO coding style. When investigating MVC, it seems clear that often a domain logic model is mixed up with persistant data access (i.e. a database) and it became clear that this is far from ideal. Since then I’ve learnt of using a data access model, and accessing that from domain logic, and thus my research into ORM started.

One thing that concerns me is a tendancy for ORM layers to have quite a high database load, or relying on PHP to do processing a DB is far more capabable of. To what extent does xPDO support the implementation of more complex queries? How would you suggest applying these to create a neat relationship between a domain/business logic model and a data access layer such as xPDO?

Forgive me if this is a little broad, I’m just trying to figure out a flexible, yet performance friendly solution, and once again thanks for the reply.

DM

Quote from: DangerMouse1981 at Jan 15, 2008, 03:29 PM

One thing that concerns me is a tendancy for ORM layers to have quite a high database load, or relying on PHP to do processing a DB is far more capabable of. To what extent does xPDO support the implementation of more complex queries? How would you suggest applying these to create a neat relationship between a domain/business logic model and a data access layer such as xPDO?

This is exactly why I authored xPDO; I had used Propel to implement a prototype of MODx and it turned out to be way too heavy, both in terms of generated OO-code, and in terms of the overhead of the O/RM layer (which in Propel also included a custom database access and query abstraction layer called Creole). By adopting native PDO to handle the database access abstraction and making query abstraction an optional layer that sits on top of the O/RM layer, xPDO provides a simple CRUD framework that is more flexible and easily extensible without any unnecessary overhead. And you can optimize platform-specific classes for specific db platforms or choose to abstract certain functions across all platforms. xPDO provides you that choice. xPDO also provides facilities for full result-set caching using a custom implementation of your choice, i.e. file-based or memcached-based caching of all SQL query results that can reduce database load to nothing in some situations.

As one example, splittingred (one of the core MODx developers) recently introduced xPDO into a custom Smarty-based framework he develops and maintains at work, replacing the PEAR MDB2 O/RM library he used previously. I believe the performance gain was two or three-fold even without using native PDO (via PDO emulation layer using mysql extension), and a recent upgrade to a PHP version with native PDO showed even more improvement. You’ll have to ask him about any other benefits or issues he’s experienced in his use of xPDO.

Quote from: OpenGeek at Jan 15, 2008, 05:14 PM

As one example, splittingred (one of the core MODx developers) recently introduced xPDO into a custom Smarty-based framework he develops and maintains at work, replacing the PEAR MDB2 O/RM library he used previously. I believe the performance gain was two or three-fold even without using native PDO (via PDO emulation layer using mysql extension), and a recent upgrade to a PHP version with native PDO showed even more improvement. You’ll have to ask him about any other benefits or issues he’s experienced in his use of xPDO.

Yep, that’s true. Also, we’ve been recently using the DB result-set caching ability of xPDO, and I’ve found it to be incredibly fast now (especially since most things now are run in AJAX calls via Ext and JSON data).

I’ve also found it massively helpful in separating code from content. I’ve been able to develop a program structure with xPDO that mimics the benefits of MVC, while also allowing for a "poor man’s web services" ability via AJAX connectors (a feature you’ll see in modx097). The result is that everything is highly extensible, incredibly easy to maintain, and ridiculously compact - with a lot of that help coming from the simple, easy-to-extend xPDO framework.

I have found some issues with xPDO’s abstraction of the SQL query in highly complex queries (specifically nested parenthetical statements in WHERE clauses), but that is easy to get around, as xPDO allows for sql-type-specific commands in your object classes (ie, Customer_mysql is used when xPDO is instantiated with a mysql DB type). So, I can write the DB type-specific, complex queries in the different subclasses, and easily switch between the two. Takes me a grand total of 5 minutes extra. (And I note these are exception cases, rather than the rule.)

I would highly recommend xPDO. There might be a slight learning curve for those not familiar with extendable ORMs, but once you get a hang of it you wont turn back. I’ve seen a lot go through PHP in my 10 years in web-dev, and I’m definitely sticking with xPDO for now.

Thanks both this is great info, I’ll definately give xPDO a bash Is it only available via SVN ? (not used it before).

Cheers for the advice, much appreciated.

DM

I recommend getting it from SVN for now; I’ll update the download packages as soon as I get some breathing room.

The HEAD revision at http://svn.xpdo.org/svn/xpdo/trunk/ should be fairly stable at this point. All feature changes and bug fixes are committed through http://svn.xpdo.org/svn/xpdo/branches/1.0/ before being committed to trunk.

As always, don’t hesitate to ask any xPDO-specific questions in these forums - it will help me start creating better documentation for it; just try to create topics for specific questions as practical.