CHAPTER 12 ■ ENTERPRISE PATTERNS
Testing is another good reason for creating systems with separate tiers. Web applications are
notoriously hard to test. Any kind of automated test tends to get caught up in the need to parse the
HTML interface at one end and to work with live databases at the other. This means that tests must work
with fully deployed systems and risk undermining the very system that they were written to protect. In
any tier, the classes that face other tiers are often written so that they extend an abstract superclass or
implement an interface. This supertype can then support polymorphism. In a test context, an entire tier
can be replaced by a set of dummy objects (often called “stubs” or “mock objects”). In this way, you can
test business logic using a fake data layer, for example. You can read more about testing in Chapter 18.
Layers are useful even if you think that testing is for wimps, and your system will only ever have a
single interface. By creating tiers with distinct responsibilities, you build a system whose constituent
parts are easier to extend and debug. You limit duplication by keeping code with the same kinds of
responsibility in one place (rather than lacing a system with database calls, for example, or with display
strategies). Adding to a system is relatively easy, because your changes tend to be nicely vertical as
opposed to messily horizontal.
A new feature, in a tiered system, might require a new interface component, additional request
handling, some more business logic, and an amendment to your storage mechanism. That’s vertical
change. In a nontiered system, you might add your feature and then remember that five separate pages
reference your amended database table, or was it six? There may be dozens of places where your new
interface may potentially be invoked, so you need to work through your system adding code for that.
This is horizontal amendment.
In reality, of course, you never entirely escape from horizontal dependencies of this sort, especially
when it comes to navigation elements in the interface. A tiered system can help to minimize the need for
horizontal amendment, however.
■Note While many of these patterns have been around for a while (patterns reflect well-tried practices, after all),
the names and boundaries are drawn either from Martin Fowler’s key work on enterprise patterns, Patterns of
Enterprise Application Architecture, or from the influential Core J2EE Patterns by Alur et al. For the sake of
consistency, I have tended to use Fowler’s naming conventions where the two sources diverge. This is because
Fowler’s work is less focused on a single technology and, therefore, has the wider application. Alur et al. tend to
concentrate on Enterprise Java Beans in their work, which means that many patterns are optimized for distributed
architectures. This is clearly a niche concern in the PHP world.
If you find this chapter useful, I would recommend both books as a next step. Even if you don’t know Java, as an
object-oriented PHP programmer, you should find the examples reasonably easy to decipher.
All the examples in this chapter revolve around a fictional listings system with the whimsical-
sounding name “Woo,” which stands for something like “What’s On Outside.”
Participants of the system include venues (theaters, clubs, and cinemas), spaces (screen 1, the stage
upstairs) and events (The Long Good Friday, The Importance of Being Earnest).
The operations I will cover include creating a venue, adding a space to a venue, and listing all
venues in the system.