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: list and 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 show is 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 UpdateAction.

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?