PHP data access design patterns to complement an ORM

Question

I've currently got a site that depends on an Active Record pattern using the Doctrine ORM in PHP. I'm generally a fan of this approach - it's very straightforward and works well for managing for simple CRUD apps. But as this site grows, I think my need for more robust domain functionality will grow as well. I was wondering what other kinds of data design patterns work well in conjunction with an ORM.

My basic problem right now is that Doctrine seems to work best as a fancy querying language, so my models are littered with methods like:

function getBySomeClassfication($classification)
{
    return Doctrine_Query::create()
              ->select('stuff')
              ->from('ModelClass')
              ->where('something = ?', $classification)
              ->execute();
}

or if I want to access a model class directly:

Doctrine::getTable('ModelClass')->findAll();

This means I end up working with Doctrine's object wrappers instead of directly on my domain objects. I feel like all this should exist at a lower level of abstraction.

I'm just not quite sure what the best approach is. I feel like the ORM is an excellent layer for querying single tables and dealing with relationships. But I'd like to have more flexibility in creating domain objects that work across multiple models/tables.

I've read up on using the Repository pattern, but still have a few hesitations:

1. I don't want to just create a pointless layer of abstraction that simply bubbles up the original problem.

2. I don't want to re-create or render useless the whole point of using an Active Record ORM.

Any thoughts or suggestions?

Answer 1

You might have a look at the Zend Framework ORM implementation(if you haven't already) where it is also possible to define relationships across multiple tables.

I hope that helps.

Answer 2

You need to work with the object wrappers (Data Access Objects) at some point and at some point your calls will be implementation (here Doctrine-) specific. It mainly depends on your current architecture on how many layers you want to put in between, but I would say - as less as possible. Is there any specific problem you have that Doctrine doesn't solve?

I sometimes don't see the point in having to deal with database specifics (e.g. one Domain Entity spreading over several tables) at all when using the ORM as a tool for (from scratch) Object Oriented Domain Model development. I recently answered a more Java specific question here, but maybe it helps you, too for the architecture idea.