CHAPTER 12 ■ ENTERPRISE PATTERNS
objects will not have been made available. Check back to the Controller class to see where the Request
object is set, and to the AddVenue command class to see the Venue object being stored on the Request.
You could simplify things still further here by making the View Helper a proxy that delegates for the
Request object’s most useful methods, saving the view layer the bother of even acquiring a reference to
Request.
Clearly, this example doesn’t banish code from the view, but it does severely limit the amount and
kind of coding that needs to be done. The page contains simple print statements and a few method calls.
A designer should be able to work around code of this kind with little or no effort.
Slightly more problematic are if statements and loops. These are difficult to delegate to a View
Helper, because they are usually bound up with formatted output. I tend to keep both simple
conditionals and loops (which are very common in building tables that display rows of data) inside the
Template View, but to keep them as simple as possible, I delegate things like test clauses where possible.
Consequences
There is something slightly disturbing about the way that data is passed to the view layer, in that a view
doesn’t really have a fixed interface that guarantees its environment. I tend to think of every view as
entering into a contract with the system at large. The view effectively says to the application, “If I am
invoked, then I have a right to access object This, object That, and object TheOther.” It is up to the
application to ensure that this is the case.
Surprisingly, I have always found that this works perfectly well for me, though you could make views
stricter by adding assertions to view-specific helper classes. If you go as far as this, you could go for
complete safety and provide accessor methods in the helper classes that do away with the need for the
evil Request::getObject() method, which is clearly just a wrapper around an associative array.
While I like type safety where I can get it, I find the thought of building a parallel system of views and
View Helper classes exhausting in the extreme. I tend to register objects dynamically for the view layer,
through a Request object, a SessionRegistry, or a RequestRegistry.
While templates are often essentially passive, populated with data resulting from the last request,
there may be times when the view needs to make an ancillary request. The View Helper is a good place to
provide this functionality, keeping any knowledge of the mechanism by which data is required hidden
from the view itself. Even the View Helper should do as little work as possible, delegating to a command
or contacting the domain layer via a facade.
■Note You saw the Facade pattern in Chapter 10. Alur et al. look at one use of Facades in enterprise
programming in the Session Facade pattern (which is designed to limit fine-grained network transactions). Fowler
also describes a pattern called Service Layer, which provides a simple point of access to the complexities within a
layer.
The Business Logic Layer
If the control layer orchestrates communication with the outside world and marshals a system’s
response to it, the logic layer gets on with the business of an application. This layer should be as free as
possible of the noise and trauma generated as query strings are analyzed, HTML tables are constructed,