Model view controller architecture has been a staple of desktop application development for a hell of a long time, with the increasing complexity of these newfangled web applications and websites in general the encapsulation and flexibility of mvc design makes darn good sense (buzzwords bolded for the executives out there). But what happens when a good design idea meets a really really evil language...

Well ok, php isn't evil per se, it's just misunderstood. Grossly, horrifyling misunderstood on a level that only economists and libertarians can appreciate (and maybe perl programmers but they enjoy that kind of thing). It's simple, php allows people to write really bad code and still accomplish whatever it is they want to do and fast. However, it is possible to write readable, maintainable code in php and using mvc will help with that. So without further ado here's my interpretation of mvc in php.

The model is the interface to the database. All database specific code goes in here. If you are using flat files, tables, and/or smoke signals do all the loading and saving in the models. Here's the model for the example.

File model: animal.mdl

These functions would be called to load a specific animal and update a animal's color. I'm trying to leave out extraneous code to make the principles more clear so don't jump all over me for a lack of error checking and whatnot. Anyway, you've got a animal in the database you need the data. You load it up and stick it into an array. Not exactly rocket science. When you want to update a animal's color you send the animal_id and the color.

Now for the controller. The purpose of this part is to act as an intermediary, controlling logic flow and massaging data for the template and model. Your controller tells the template what parts of the page to display and how to display them. Here's the example:

File controller: Animal.php

This isn't going to make a whole lot of sense until you see the template file so here it is:

File template: Animal.tmpl The controller is the page you would link to from other parts of your site. In this case it would probably be called from a page with a list of animals, each being a link with a url like: Animal.php?animal_id=23

Before it includes the template, the controller calls on the model to load the data from the database.

The form calls the controller when the update button is pressed. Then the controller tells the model to update the databse. The important part here is that the template is only concerned with the interface to the user.

Splitting your code up this way will make your life so much easier it's ridiculous. With this design you can load up a controller and quickly get an idea of the logic flow of a page. You can swap out different data sources with a minimal amount of rewrites and you can pass off designing the templates to an artist with minimal php knowledge, or have them do mockups and you fill in the php. MVC is a Good Thing(tm), you should use it.