The basic behavior of a web server is to respond to HTTP requests while maintaining some state between requests. A classic way of separating this process into smaller subprocesses is to define:
A dispatch procedure: given an URL, how to decide which piece of code should be run?
- The default for Apache-PHP is that when the user enters the URI of a server-side PHP script, Apache runs the code in that script. While that is certainly sufficient for many applications, it causes a cumbersome “.php” extension to appear in the URL and may lead to security issues where PHP files that are not intended for execution (only inclusion from other files) are visited by the user.
- Many frameworks (such as Zend) instead decide that only one file should be executed (usually an index.php file) with all visits being dispatched there by means of URL rewriting. This has several benefits, such as providing a single entry point from where every other file can be accessed, and also allowing more clever dispatch rules.
- In this article, I will be using an htaccess-based rewriting system.
Controllers: a controller is the piece of code that gets executed when a certain URL has been dispatch. In general, every high-level part of a website is handled by a different controller. The main tasks of a controller are:
- To parse the user request: extract the various parameters, check whether they are correct, and what should be done with it.
- To adjust the server-side persistent state based on the request. This is usually done through the model.
- To respond to the user with the appropriate data. In some cases, the output will be formatted by using a view.
Models: a model is the brick that lets the controller access the persistent state. This includes session data, any databases, files on the filesystem, and so on. The objective of a model is that the data is encapsulated: if there are constraints (such as, “no two users may have the same name”) then it is the responsibility of the model to ensure that these constraints are respected. Of course, it helps if the controllers also respect the constraint, but the model should never let a controller ignore it.
Views: a view is, mostly, a formatting tool. It reads data in a specified format (which, for the sake of simplicity, is identical or reasonably similar to the data format that is provided by the model) and reformats it as HTML for the user to vew. Views are dumb, standalone things: they don’t have any side effects, nor do they write to any part of the system.
Hi. I'm Victor Nicollet,
0 Responses to “1. Global Architecture”