In the last two essays we established that there is a dispatcher, multiple controllers and multiple actions. The dispatchers creates a controllers and calls the action. Why do we split the application into these parts?
First the Dispatcher. The Dispatcher applies rules to a URL and chooses the corresponding Controller and Action. The Controller is a container for action and applies some default values to the action. The Action contains the code that’s necessary to perform some transformation on the application data.
By structuring the design like this, the only task for the Controller is as a
container for actions. We group the Action together with semantically similar
actions. Actions that apply to the same type of information, e.g. the Guestbook
controller contains the two actions:
add_entry. The first action
shows a list of guest book entries, the second action adds a new entry to the
list. On the surface it makes sense to group Action like this in the
controller. The action in the controller perform operations on the same
data type, e.g. the list of guest book entries.
If we begin with Actions instead, then we can structure the application in
another way. Each type of Action gets its own class, e.g. the action
performed by the
ShowAction class. The
ShowAction contains the code for
showing one data item. It could be possible to generalize the code for every
type in the system. And like the
ShowAction we can also create an
EditAction and an
The controller based structure enables us to spell out every part of the computation, from beginning till end. We’re free to do whatever we want. The action based structure forces us to become more structured programmers. The action can’t contain any specific code. We’d have to write Actions for every action in the system.
I think it’s better if we specify and generate code for the specific differences and let the general case be handled by the Action class. On the other hand couldn’t we apply these lessons to a Controller based model?