15 March 2007
Comparing monolithic controllers with task-based controllers
When programming in a MVC paradigm, a common question is whether to use one big controller or many smaller ones (and the smaller question of whether or not to use model-based controllers).
Consider the advantages of each: with a monolithic controller, your application has a single point of entry. All code, configuration and files you wish to control can be completely removed from the web root. Common naming conventions are easy to enforce. Tools like mod_rewrite become unnecessary — it is inherently part of your point-of-entry. Abstracting away the physical filesystem path can allow more flexibility in resolving paths in code.
With a task-based controller, you can take advantage of the tools the web server offers you. Under apache, that means HTTP authentication comes for free. Mod_rewrite is available. Action names can be reused because each instance is sandboxed to a controller. And as is the policy of this site, the code can avoid a layer of complexity and as such has a lower learning curve.
Some projects blur the lines. With Cake, for instance, there are multiple controllers but every request is funneled through index.php. This fact is hidden away with a myriad of mod_rewrite rules. This causes a loss of available webserver functionality, for HTTP authentication is no longer easily applies. It also manages to lose the consistency that monolithic controllers enforce.
One hesitation I have towards the monolithic controller is that it is redundant to the webserver. Your domain is already a single point-of-entry to the site, and Apache (or IIS) plays the role of determining which file (action) to process. A monolithic controller duplicates this functionality. There are times that this is ideal: a large site comprised of dynamic data and no administrative part would be a good candidate for a design like this. Uniformity can be enforced and good application design encouraged.
What’s interesting about that design is that it is a single task-based controller. The controller could be considered a WebsiteController with each action a file. While it is still redundant compared to Apache’s primary purpose, it affords hooks for common design chrome. Instead of each file including a header, navigation, sidebar and footer, the files can be nothing more than content. The controller knows with what each file should be surrounded.
Task-based controllers are nearly always the answer. As a developer, it’s your job to identify what those tasks are. And you must be careful to identify not by what’s easiest to do, but what is most natural. Capture the concept in the controller, and the details in the action. MVC programming has a learning curve to it, but once you’ve conquered it, MVC programming will be a very natural, for a well designed MVC will match the way you think.