CHAPTER 12 ■ ENTERPRISE PATTERNS
The Patterns
These are the patterns I explore in this chapter. You may read from start to finish or dip in to those
patterns that fit your needs or pique your interest. Note that the Command pattern is not described
individually here (I wrote about it in Chapter 11), but it is encountered once again in both the Front
Controller and Application Controller patterns.
- Registry: This pattern is useful for making data available to all classes in a process.
Through careful use of serialization, it can also be used to store information across
a session or even across instances of an application. - Front Controller: Use this for larger systems in which you know that you will need
as much flexibility as possible in managing many different views and commands. - Application Controller: Create a class to manage view logic and command
selection. - Template View: Create pages that manage display and user interface only,
incorporating dynamic information into display markup with as little raw code as
possible. - Page Controller: Lighter weight but less flexible than Front Controller, Page
Controller addresses the same need. Use this pattern to manage requests and
handle view logic if you want fast results and your system is unlikely to grow
substantially in complexity. - Transaction Script: When you want to get things done fast, with minimal up-front
planning, fall back on procedural library code for your application logic. This
pattern does not scale well. - Domain Model: At the opposite pole from Transaction Script, use this pattern to
build object-based models of your business participants and processes.
Applications and Layers
Many (most, in fact) of the patterns in this chapter are designed to promote the independent operation
of several distinct tiers in an application. Just as classes represent specializations of responsibilities, so
do the tiers of an enterprise system, albeit on a coarser scale. Figure 12–1 shows a typical breakdown of
the layers in a system.
The structure shown in Figure 12–1 is not written in stone: some of these tiers may be combined,
and different strategies used for communication between them, depending on the complexity of your
system. Nonetheless, Figure 12–1 illustrates a model that emphasizes flexibility and reuse, and many
enterprise applications follow it to a large extent.
- The view layer contains the interface that a system’s users actually see and interact
with. It is responsible for presenting the results of a user’s request and providing
the mechanism by which the next request can be made to the system.