http://pastebin.se/195238

Or how exactly is it handled in a smooth’n'efficient way?

The implicit caching with the identity map is indeed a minefield, but you shouldn’t really clone a domain object now should you? And the race condition will always exist in one way or another no matter how much you try to work around it (at least in php) due to the nature of php and it’s share-nothing-architecture, no?

Also, I spotted that you use implicit caching in your example. This is a great idea, but it is also a minefield. Imagine if I clone one of your object instances, change a field and save it. Worse yet, imagine that another concurrent script execution modifies and saves it. This inevitably means that all subsequent code in the current execution will break, because any subsequent request for the object would return an inaccurate copy of an object, which will be modified and saved back eventually, resulting in mysterious data loss that is nearly impossible to debug.

Kyle:
Yes, in fact the original article and examples had a LazyLoad class that worked like a proxy for the User-object in the Post, but I felt that the examples became to complicated and the article was getting to long so I decided to cut it as I thought of this as more of a introduction do DO/DM:ing then a “complete” guide to all techniques you can use (locking, unit-of-work, value fields, etc.), maybe for a follow up article. The thing about writing articles is to know where to limit yourself, I could’ve written a smaller doctoral thesis on this subject ;p

About the getObjectForRow()-method, I think I just missed putting protected in front of it and creating an abstract base method in DataMapper(), or I could’ve left it out on purpose to keep things clear - don’t remember.

Also I wouldn’t tangle the Domain Objects with knowledge of the mappers, as one of the main benefits of using a Data Mapper is that your DO’s are completely ignorant of any type of database / persistence and can act as pure in memory objects.

- Fredrik

I’m working with a similar approach for a while now an the only drawback of your solution is, that for larger tables resolving associated classes immediately (like in Post->User) might be a performance issue - especially when using your implementation of PostMapper::findAll(). Using lazy loading for associated classes - in most cases - solves such problems.

So, one would have an internal variable $_userId (or whatever) and the implementation of Post->getUser() would be like this:

class Post
{
// …
public function getUset() { UserMapper::find( $this->_userId ); }
// …
}

This solves also the problem of association chains: Imagine an enhanced version of your model, where you have (multiple) addresses associated to users. In other words you have a foreign key from the address table to the user table and from the post table to the user table. You’d have to change your implementation of PostMapper::findAll(), which in first place has nothing to do with the address table (and IMHO should’t have to).

And further more the PostMapper::getObjectForRow() doesn’t return a valid object when called not from within findAll(). Public interfaces shouldn’t depend on the the way they are used.

And to finally spin the wheel a bit further: Think of a solution that hides the concrete persistence layer behind the DomainObject (the persistence layer might be changed from database to XML or a concrete db to another (MySQL to Oracle)). The DomainObject would then function as a bridge to the Mapper like this:

$yoda = new User( “Yoda” );
$yoda->save();
var_dump( $yoda );
$yoda2 = User::find( $yoda->getId() );

Regards, Kyle