CHAPTER 12 ■ ENTERPRISE PATTERNS
Some of this code will make more sense in the next chapter. For now here's a stub Venue object that
would work with this command:
namespace woo\domain;
class Venue {
private $id;
private $name;
function __construct( $id, $name ) {
$this->name = $name;
$this->id = $id;
}
function getName() {
return $this->name;
}
function getId() {
return $this->id;
}
}
Returning to the command, the key thing to note is that the doExecute() method returns a status
flag that the abstract base class stores in a property. The decision as to how to respond to the fact that
this object has been invoked and has set this status is entirely driven by the configuration file. So
according to the example XML, if CMD_OK is returned, the forwarding mechanism will cause the AddSpace
class to be instantiated. This chain of events is triggered in this way only if the request contains
cmd=AddVenue. If the request contains cmd=QuickAddVenue, then no forwarding will take place, and the
quickaddvenue view will be displayed.
Note that this example does not include any code for saving a Venue object to the database. I’ll get to
that in the next chapter.
Consequences
A fully featured instance of the Application Controller pattern can be a pain to set up because of the
sheer amount of work that must go into acquiring and applying metadata that describes the
relationships between command and request, command and command, and command and view.
For this reason, I tend to implement something like this when my application tells me it is needed. I
usually hear this whisper when I find myself adding conditionals to my commands that invoke different
views or invoke other commands according to circumstances. It is at about this time that I feel that
command flow and display logic are beginning to spiral out of my control.
Of course, an application controller can use all sorts of mechanisms to build its associations among
commands and views, not just the approach I have taken here. Even if you’re starting off with a fixed
relationship among a request string, a command name, and a view in all cases, you could still benefit
from building an application controller to encapsulate this. It will give you considerable flexibility when
you must refactor in order to accommodate more complexity.