The Model-View-Controller Design Pattern in Web Development
Design patterns are a tool for making software projects more manageable. They provide sorely-needed structure to projects containing thousands of lines of code. More importantly, they represent conventional wisdom that can be applied to the top-down development of many projects before they even begin. Abstractly, most software projects will fit into a design pattern quite nicely.
When CGI programming first hit the web, it was new unexplored territory. Code was short. Applications were small. Because output was HTML, text processing languages like Perl became standard. In the pursuit of larger applications, developers created their own styles and conventions to manage the growing complexity. The wheel was now solidly reinvented. But once these ideas become engrained, older developers recognized that MVC categorizes the flow of most web applications very nicely. Why?
The Model
The Model in MVC parlance refers to the data the application uses. All applications use data, but the web in particular is data-oriented. Sure, some web applications make light use of data, but its safe to assume that most web applications are all about presenting data, often from an internal database. Combine that fact with the untrusted nature of network communications, and you have a scenario where you need strict control over your data. Encapsulating this control in a Model (as opposed to strewn about the entire application code) means data tends to stay healthier.
The View
The View creates the output of the application that the user sees. Its difficult to separate from the controller completely, but the web makes it much more straightforward with its document-centric protocol. The view should be responsible for outputting pages to the web browser in HTML format. Compared to a GUI where the API may inherently muddle the separation from the controller, the web makes a natural distinction.
The Controller
The Controller processes input, deciding which data is needed, any actions that need to be performed, and lets the view know what it needs to display. In essence, the contoller is the catchall for everything the Model and View shouldn't be doing. On the web this tends to be pretty straightforward as everything comes in the form of distinct requests.
Implementation
So how does it all fit together in web development? A design pattern is inherently abstract, you don't necessarily have a class for each letter in the acronym. In fact, you don't even really need to use object-oriented programming to design applications this way. The important thing is keeping the components modular and focused. For web development, the components are usually implemented as such:
The Model maps database contents to application objects that are usable by the Controller and View. This means the model is responsible for all database interaction, data validation, and creating a standard representation of various types of data.
The View is generally comprised of a series of HTML templates with very minimal dynamic code. Code can't be removed from the View entirely, because it is, after all, displaying dynamic data. But the code should be limited to formatting standard representations of data, it should never munge the data itself.
The Controller just interprets input from incoming requests calling on the Model to make any necessary data modifications, as well as fetching the right data for use by the View. In practice, the Model usually implements some kind of direct data access so that the Controller can mostly get by with high-level data units (eg. users) and the View can use the Model directly to output specific data (eg. username, last login date, etc).
Frameworks
These days, pre-written MVC frameworks are all the rage. Using a framework properly not only makes it easier to develop large web applications (hopefully), but it also makes it easier to understand them by standardizing how the code is structured. Not only that, but web development is full of repetitive tasks which are suitable for automation. Web frameworks provide hunks of functionality in a more convenient fashion than simple libraries or modules.
Here are some current frameworks:
- Java Struts (http://struts.apache.org/)
- Perl Catalyst (http://catalyst.perl.org/)
- PHP Studs (http://www.mojavelinux.com/projects/studs/)
- PHP Cake (http://cakephp.org/)
- Python Django (http://www.djangoproject.com/)
- Ruby Ruby on Rails (http://www.rubyonrails.org/)