A gentle introduction to MVC (part 2)

In part 1, we saw how to decouple a traditional vanilla PHP script so as to separate business logic from presentation. This was the biggest step to make: from now on, we are just going to finetune this separation by adding a 3rd guy in the equation: the model. Ladies and gentlemen, this is part 2 of A gentle introduction to MVC.

Part 2: fully MVC-powered goodness

MVC stands for Model/View/Controller. It’s a software design pattern advocating the use of three layers:

• the model: the model is the data access layer, the one responsible for gathering the data asked by the request (i.e. functions like getAllMembers() returning a PHP array with all the members in it, or addMember($name, $age, $city) to add a new member to the database)
• the view: the view is the presentation layer in charge of generating the output (i.e. the final HTML webpage featuring the names of the members with PHP used as a template language as in <li><?php echo $member['name']; ?></li>)
• the controller: the controller is aimed at coordinating the whole process by analysing the request, running the corresponding model to get the data (i.e. calling getAllMembers() and put the return array in the PHP variable $members), call the corresponding view (i.e. include 'tpl/template.php') and fill it with the data (i.e. $members), and then send the final output back

Here is a simple graph to better understand the MVC design pattern:

This new architecture gives more flexibility when building the application:

• the data access layer is outsourced to the model so that we can work with an abstraction of data: the actual storage of data may be a database, XML files or a hash table, we will still access the list of members through the function getAllMembers()
• the presentation layer is outsourced to the view: if we want the output to be a RSS feed instead of a HTML page, we just have to change the view without interfering with the logic or the data access

As you can see, MVC is extremely powerful because it makes it possible to split down the script in naturally independant parts, which in turn makes the old reusability dream come true: for example, if we want to output both a HTML page and a RSS feed featuring all the members of community.com, we can reuse the same model and simply create two different templates (say 'tpl/template.php' and 'tpl/rss.php').

Now let’s turn to a substantial implementation of the MVC design pattern. Calling directly the controller through http://community.com/members.php can be enhanced through a little bit more of decoupling: instead of calling directly the script, we will call a single-entry point called the router specifying that we want to display the members’ page, and this router will analyze the request, understand that we want to display the members’ page and run the members.php controller. In CodeIgniter for example, the single-entry point is called index.php and if we want to call the members controller, we have to type the following url: http://community.com/index.php/members. We could also imagine a less-sexy http://community.com/index.php?controller=members or, on the contrary, get rid of the router through some URL rewriting and just having to call an elegant http://community.com/members.

Here is what we have added or clarified in this example of MVC implementation:

• the router is now the single entry-point of the application which analyzes each request and loads the corresponding controller
• the model interfaces with a database (once again, it could be a set of XML files or any other way of storing data, we would just have to rewrite the model without worrying about the final output providing that we deliver the expected data)
• the view now becomes a main layout which in turn can include reusable sub-templates (this is directly inspired from Ruby on Rails and has been reproduced in many web frameworks)

(Go to part 3)