The real world
Web development is, in many cases, a process where time is a crucial factor. As coding is usually the last step in the process, all things come together and prior mistakes are revealed.
"Build this so it looks the same in all browsers, works better than the IA was ever planned and can fly." Or so we hear.
With a limited amount of time, developers are often tempted to fall for quick fixes and, not only due to last-minute changes, find themselves in a huge ball of code at the end of the project.
"What does that matter, if the site is working nicely, nobody complains and it's nodded off by the client?" I hear you ask.
This attitude is something I've encountered many times, and it usually results in a second-phase disaster, be it an extension of the site, a new face or a server change.

Theory
This is where the MVC comes to the rescue. It's basically an attempt to structure a web application into three components:

• Model is generally understood as the data-administration component. In the majority of website projects, this is the data retention in a relational database system, but it could also include other persistent business objects, Enterprise Java Beans for example. Model is passive and does not trigger any actions. Data is requested independently of their representation (view); Model does not know anything about the data presentation. Model can work with one (1:1-relation) or several Views and Controllers (1:n-relation).


• View describes the visual representation of the Model. In the case of many dynamic websites, you would imagine one or two Views on the same Model: in the case of this article, one would be the public View - the way you see this article now, and another one would be where I create and edit. Of course, there are many more possibilities: different user levels, each with a distinctive set of permissions; different representations of the same website for regular users; high contrast for easier reading; a View without head and navigation for printing, and so on.


• The Controller has the entire application logic implemented. It is an active component. The application receives inquiries, passes it on to the responsible subcomponents in the system and possibly sends answers back to the user. The Controller carries out various manipulations of the Model for the execution of user actions.

So far, so good. Now that the theory is clear, we can look at how it's used in the web development process. Do I actually need it? This seems to be a very sensitive subject. While researching, I've found several approaches, most are somewhere in the triangle of determined, angry and ignorant. I'd like to point out the most obvious reasons to use it, hopefully not stepping on any toes:

• Match a thought pattern: Putting your code into a programming pattern is difficult when you try doing it while coding, but the idea is to structure the code first, in your head, on a piece of paper or, for large scale projects, with CASE-tools. With the structure documented, your code becomes more manageable, and the number of people that want to see you roast in hell (possibly you yourself in 1 or 2 years time) is decreasing. Every developer that understands MVC will find their way through your stuff quickly, you will both work on the same wavelength, because you both follow the same pattern, in code and thought.


• Reusability. This goes for any kind of modularisation, but it's an argument not to ignore: Once you have thought through and set up your model, you can reuse it many times with no or only minimal changes.


• Extendibility: With a strict modularisation, you have a defined field of work when it comes to changes of face, functionality or data storage. Depending on your web applications needs and real-world situation, you can decide which parts need upgrading.

Practice
I discovered that Jakarta Struts is a really good Java-based solution and, more recently, PHP Architect magazine offered a free download of their may 2003 issue, containing a nice introductory article with a solution based on Smarty templates. A very extensive solution incorporating the three-tier architecture (no, they're not the same) also PHP-based, can be found on Tony Marston's website along with tons of information on different design patterns.
I could stop here and leave you with one of the examples, but let me say this: I believe that the size of the project and the probability of exchanging or updating certain components should play as important a role as the reusability of the code.
Over time, Pascal and I have come up with a loose framework of PHP classes, which have saved enormous amounts of time when building medium-scale projects, thanks to their reusable subcomponents.
The Views are set up with CSS and (X)HTML, which is generated with XSL stylesheets.
In the backend PHP, classes are structured by their functionality. A db-class manages all lower-level database work: replace it or change the configuration for a database change. This class represents the Model. Your server was hacked and you need to refer to a backup db-server? It's done in 10 seconds.
A base class, meanwhile, carries all of the helper functions that are used across most projects, for things like string and date operations. It is extended by a page class, which is the first class to adapt to the project. Here, the site structure is taken care of (usually dug out of the database in one way or another, as a tree or a flat page model), functions for breadcrumbs and navigation grab the data and return the XML, and global site elements find their data. But not only that: All what's generally called business logic, calculations, workflows and so forth, can be found here as well. The class can then be extended for special purpose pages, to keep it nice and tidy. I group them as Controller. They receive all the requests, they instantiate the Model (the db class) to deliver XML, to be transformed by the View, by XSL.
But this does not strictly fit into the MVC pattern: In a clean approach, no SQL would be found in the page class. A common technique here is to set up a class for each table that contains all queries. This way, you know where to find your SQL and what classes to touch should your db-server change. Alternatively, you can extend the db-class and top it up with higher level of functions that build the SQL for you. On the upside, you only have one file to change (as opposed to one per table); on the downside, solutions tend to be developed in a complicated way, thereby making it difficult for the next developer to get their head around it. Furthermore, it may be too specific to one site and, therefore, not very portable.
With these classes set up as a starter package, you'll have incredibly quick results - and working as a frontend/backend team is a joy. Simply set up an abstract XML file with all the data you need, and each of you can work towards it from both sides: one on the xsl/html/css side, the other in the php/db department.
On several occasions, I left out the table classes as a set-up for medium-sized projects. As an alternative, I either stuck to relational databases (usually sufficient) and coded in pure SQL-92 - although this tends to be awkward and I'm not sure if all common databases follow this standard entirely - or I made sure the db-application stayed the same throughout the lifetime of the site.
As with most things in modern digital life, sites are ever-changing, but the code hardly ever survives three years. Your budget, timeframe and the purpose of the site will determine to what extent you want to follow MVC. But it's always worth considering.

Original: MVC in smaller web applications