Everything's a draft

This article was originally posted on April 19th 2009

Everybody who has projects that exist out of more than 100 lines of code faces the problem of keeping his code clear, and maintaining a good oversight. Of course, none of us wants to go over all his code just to find that one line or method you’re looking for.

To overcome this problem, some smart people ‘invented’ Design Patterns a long time ago. A design pattern is ‘a general reusable solution to a commonly occurring problem in software design.’ (Wikipedia). A commonly used design pattern is MVC: Model–view–controller. MVC is used to separate your application in three parts: the Data (Model), the output (View), and the User action/input (Controller).



The Model: This is used to retrieve and store data used anywhere in your application. This data is also called the domain, please note that this has got nothing to do with domain names!The storage can be basically anything, from fullblown Oracle Databases to Sessions, from the Google APIs to Punched Cards. The nice thing of this is that whenever you want to change storage, or something inside the storage is changed (like a row in your db-table is renamed) you only have to apply the changes once at only one place.

Especially in terms of Web Applications almost every application is useless without output, this is where the view comes in. The view retrieves data from your model or controller, and displays it in a way that a user can understand it. mostly this will just be some (x)html page. Sometimes some logic needs to be done before the data from the model can be displayed to a user. Now you can of course put the code that is responsible for that in your view. However, a lot of people don’t like having logic in their views, and chances are that you need the same logic in multiple views. Please do not put this logic in your models nor controllers; it has got nothing to do with either data retrieval nor handling user input. Though it isn’t part of the MVC pattern, it is considered best practice to put them in view helpers. These are reusable blocks of code that are aimed specifically at what data should look like to an end-user.

Maybe most abused by developers is the controller. The ‘nice’ thing of controllers is that you can (read: are physically able to) put all your code in your controller. All that a controller does (or should do) is parse the user input, and decide what view to use. The parsed user input can be passed on to the View, which in turn can call the appropriate models with the user parameters that were passed on by the controller. These days it is considered good practice to leave your controllers as empty as possible. I had a good link here, but it went down. The updated url is this one.

Now please remember that a design pattern is solely a guideline on a best-effort basis. There are no solid rules, and there are always exceptions to think of. While programming, such exceptions may come to your mind very often because of deadlines, hurry, a girlfriend, other projects, laziness, or any other ‘good’ reason. To help you defy these exceptions, there are a few golden rules (in random order):
» Views or models should never invoke user parameters directly.
» Models should never contain stuff that is related to the view
» Controllers and Views should never contact a database or contact a third-party API (or any other kind of storage)I.
» Models should be able to work independently from Controllers and Views
» Views should never insert something directly into a model

Because HTTP is a stateless protocol, some of the old rules of MVC cannot be complied with. Therefore, I have altered this picture a bit, just in case some things were not clear yet. This will generally be the dataflow in a stateless webapplication using MVC:


If you still have questions about MVC, feel free to leave a comment, or simply pay a visit to #zftalk @ Freenode