CHAPTER 13 ■ DATABASE PATTERNS
Figure 13–11. Some of the persistence classes developed in this chapter
A client coder might then go on to acquire a collection of Venue objects:
$idobj = $factory->getIdentityObject()->field('name')
->eq('The Eyeball Inn');
$collection = $finder->find( $idobj );
foreach( $collection as $venue ) {
print $venue->getName()."\n";
}
Summary
As always, the patterns you choose to use will depend on the nature of your problem. I naturally
gravitate toward a Data Mapper working with an identity object. I like neat automated solutions, but I
also need to know I can break out of the system and go manual when I need to, while maintaining a
clean interface and a decoupled database layer. I may need to optimize an SQL query, for example, or
use a join to acquire data across multiple tables. Even if you’re using a complex pattern-based third-
party framework, you may find that the fancy object-relational mapping on offer does not do quite what
you want. One test of a good framework, and of a good home-grown system, is the ease with which you
can plug your own hack into place without degrading the overall integrity of the system as a whole. I love
elegant, beautifully composed solutions, but I’m also a pragmatist!
Once again, I have covered a lot in this chapter. We examined the following patterns: