CHAPTER 12 ■ ENTERPRISE PATTERNS
As a rule of thumb, if I estimate a system should take me less than a week or so to complete, and that
it isn’t going to need more phases in the future, I would choose Page Controller and benefit from fast
turnaround. If I were building a large project that needs to grow over time and has complex view logic, I
would go for a Front Controller every time.
Template View and View Helper
Template View is pretty much what you get by default in PHP, in that I can commingle presentation
markup (HTML) and system code (native PHP). As I have said before, this is both a blessing and a curse,
because the ease with which these can be brought together represents a temptation to combine
application and display logic in the same place with potentially disastrous consequences.
In PHP then, programming the view is largely a matter of restraint. If it isn’t strictly a matter of
display, treat any code with the greatest suspicion.
To this end, the View Helper pattern (Alur et al.) provides for a helper class that may be specific to a
view or shared between multiple views to help with any tasks that require more than the smallest
amount of code.
The Problem
These days it is becoming rarer to find SQL queries and other business logic embedded directly in
display pages, but it still happens. I have covered this particular evil in great detail in previous chapters,
so I’ll keep this brief.
Web pages that contain too much code can be hard for web producers to work with, as presentation
components become tangled up in loops and conditionals.
Business logic in the presentation forces you to stick with that interface. You can’t switch in a new
view easily without porting across a lot of application code too.
With many operations recurring from view to view, systems that embed application code in their
templates tend to fall prey to duplication as the same code structures are pasted from page to page.
Where this happens, bugs and maintenance nightmares surely follow.
To prevent this from happening, you should handle application processing elsewhere and allow
views to manage presentation only. This is often achieved by making views the passive recipients of
data. Where a view does need to interrogate the system, it is a good idea to provide a View Helper object
to do any involved work on the view’s behalf.
Implementation
Once you have created a wider framework, the view layer is not a massive programming challenge. Of
course, it remains a huge design and information architecture issue, but that’s another book!
Template View was so named by Fowler. It is a staple pattern used by most enterprise programmers.
In some languages, an implementation might involve cooking up a templating system that translates
tags to values set by the system. You have that option in PHP too. You could use a templating engine like
the excellent Smarty. My preferred option, though, is to use PHP’s existing functionality, but to use it
with care.
In order for a view to have something to work with, it must be able to acquire data. I like to define a
View Helper that views can use. From this, they can get access to the Request object and, through it, to
any other objects that they need to do their job.