The MVC Front Controller Pattern »
FERDY CHRISTANT - JUL 23, 2008 (07:43:35 PM)
A very common, modern way of developing web applications in any platform is to apply the MVC (Model View Control) design pattern, which roughly works as follow:
- The View displays data supplied by the Model. Typically, this is done using a templating system.
- In the View, users generate actions (by visiting a URL or clicking a button) that get mapped to a Controller.
- The Controller recieves the event, checks it (validation, security, logging, etc) and where needed requests or updates data in the Model.
- Finally, the controller will redirect the user to the action result page, again making use of the Model to display data.
Code Igniter, a PHP MVC framework that I use to develop JungleDragon™, has implemented the MVC pattern as described above. There is a nice little extra though: the Front Controller. Combined with Code Igniter's excellent URL routing, you can do some pretty powerful, elegant things. Allow me to explain...
Let's have a look at the following URL:
This would trigger the Front Controller (index.php) to be requested, since no explicit controller was passed in the URL. Since no controller method was passed either, the default method index() will be called. What about this one:
You'd expect this URL to trigger the register controller, but this is not the case. What happens is that again the Front Controller is called (index.php), which will dispatch control to the register controller (using the register controller's default method index()). One more example:
You've guessed it. Again the Front Controller (index.php) is called, which dispatches control to the articles controller. From the articles controller,the method edit() is called passing in the argument "lion".
In summary, no matter what URL get's triggered, the Front Controller is always called first, even though this is transparent to the end user. Why is this so great? Here are a few things I could come up with:
- Centralized loading of global libraries and variables that are needed on every page
- Centralized logging and statistics logic
- Centralized authentication and session handling
- Centralized error reporting
- Centralized caching logic
Having a Front Controller as the entry point to all other controllers is like having a little web server inside your application. I'm definitely excited about this.
There's one more thing I wanted to show you concerning Code Igniter's URL routing. Have a look at this example:
Code Igniter allows you to map extensions to controllers. In this case, the user (and any crawler) sees what appears to be a static URL. In reality, the Front Controller is still called, which will dispatch control to the articles controller to display the item "lion". Not only does this provide pretty URLs, there's two other major advantages:
- I can move around and rename scripts, change my host, and in the most extreme case, even switch platforms, without any user needing to update their bookmarks ever.
- Should I have a need for a caching mechanism later on that generates static HTML files, no user needs to update their bookmarks as the URLs never link to any script or platform-specific extension.
Concluding, a Front Controller combined with proper URL routing makes the life of you, your users, and search engines easier :)
Note: You can still make use of a Front Controller even though you do not use Code Igniter or PHP at all. Technically, it consists of only two parts:
- Rewrite rules for the URLs, either at the level of your web server or at the level of your application. For Apache, this is simply a .htaccess file.
- The Front Controller script, which parses the segments of the URL and dispatched control to the right controller based on these segments.