PHP Objects, Patterns and Practice (3rd edition)

(Barry) #1
CHAPTER 12 ■ ENTERPRISE PATTERNS

Although serialization is a pretty efficient business in PHP, you should be careful of what you save. A
simple-seeming object may contain a reference to an enormous collection of objects pulled from a
database.
Registry objects make their data globally available. This means that any class that acts as a client for
a registry will exhibit a dependency that is not declared in its interface. This can become a serious
problem if you begin to rely on Registry objects for lots of the data in your system. Registry objects are
best used sparingly, for a well-defined set of data items.


The Presentation Layer


When a request hits your system, you must interpret the requirement it carries, then you must invoke
any business logic needed, and finally return a response. For simple scripts, this whole process often
takes place entirely inside the view itself, with only the heavyweight logic and persistence code split off
into libraries.


■Note A view is an individual element in the view layer. It can be a PHP page (or a collection of composed view


elements) whose primary responsibility is to display data and provide the mechanism by which new requests can


be generated by the user. It could also be a template in a templating system such as Smarty.


As systems grow in size, this default strategy becomes less tenable with request processing, business
logic invocation, and view dispatch logic necessarily duplicated from view to view.
In this section, I look at strategies for managing these three key responsibilities of the presentation
layer. Because the boundaries between the view layer and the command and control layer are often
fairly blurred, it makes sense to treat them together under the common term “presentation layer.”


Front Controller


This pattern is diametrically opposed to the traditional PHP application with its multiple points of entry.
The Front Controller pattern presents a central point of access for all incoming requests, ultimately
delegating to a view the task of presenting results back to the user. This is a key pattern in the Java
enterprise community. It is covered in great detail in Core J2EE Patterns, which remains one of the most
influential enterprise patterns resources. The pattern is not universally loved in the PHP community,
partly because of the overhead that initialization sometimes incurs.
Most systems I write tend to gravitate toward the Front Controller. That is, I may not deploy the
entire pattern to start with, but I will be aware of the steps necessary to evolve my project into a Front
Controller implementation should I need the flexibility it affords.


The Problem


Where requests are handled at multiple points throughout a system, it is hard to keep duplication from
the code. You may need to authenticate a user, translate terms into different languages, or simply access
common data. When a request requires common actions from view to view, you may find yourself
copying and pasting operations. This can make alteration difficult, as a simple amendment may need to

Free download pdf