CHAPTER 12 ■ ENTERPRISE PATTERNS
$this->spaces->add( $space );
$space->setVenue( $this );
}
function setName( $name_s ) {
$this->name = $name_s;
$this->markDirty();
}
function getName( ) {
return $this->name;
}
}
There a few points that distinguish this class from one intended to run without persistence. Instead
of an array, I am using an object of type SpaceCollection to store any Space objects the Venue might
contain. (Though I could argue that a type-safe array is a bonus whether you are working with a database
or not!) Because this class works with a special collection object rather than an array of Space objects, the
constructor needs to instantiate an empty collection on startup. It does this by calling a static method on
the layer supertype.
■Note In this chapter and the next I will discuss amendments to both the Venue and Space objects. These are
simple domain objects and share a common functional core. If you’re coding along, you should be able to apply
concepts I discuss to either class. A Space class may not maintain a collection of Space objects for example, but it
might manage Event objects in exactly the same way.
$this->spaces = self::getCollection("\woo\domain\Space");
I will return to this system’s collection objects in the next chapter, for now, though, the superclass
simply returns an empty array.
I expect an $id parameter in the constructor that I pass to the superclass for storage. It should come
as no surprise to learn that the $id parameter represents the unique ID of a row in the database. Notice
also that I call a method on the superclass called markDirty() (this will be covered when you encounter
the Unit of Work pattern).
Consequences
The design of a Domain Model needs to be as simple or complicated as the business processes you need
to emulate. The beauty of this is that you can focus on the forces in your problem as you design the
model and handle issues like persistence and presentation in other layers—in theory, that is.
In practice, I think that most developers design their domain models with at least one eye on the
database. No one wants to design structures that will force you (or, worse, your colleagues) into
somersaults of convoluted code when it comes to getting your objects in and out of the database.