Understanding MVC: The Basics

I’m planning on writing several posts on the Yii framework (for PHP 5), which I’ve been using for the past several months. Before getting into that, though, I thought it’d be worth while to write about the MVC—Model-View-Controller—architecture first. MVC (first defined 30 years ago!) has become a standard approach for frameworks and many other types of application development, where the emphasis is on separating presentation from logic. By taking this route, you can more easily tweak individual parts without (hopefully) breaking the whole.

The basic concept is relatively simple to understand, but I found that the actual implementation of the pattern can be tricky. In other words, it can take some time to master where you put your actual code. In this post, I write about the individual pieces and how the relate to each other. In a follow-up post, I’ll write about how to communicate between them, and what in the world $this means at any particular point!The MVC pattern breaks an application into three distinct parts:

• Model, which represents the data
• View, which is the interface (i.e., how the user interacts with the data)
• Controller, which are the actions

I think the Model is easiest to comprehend as it’s the data being used and manipulated. Models are often tied to database tables, where one instance of a Model represents one row of data from one table. Note that if you have two related tables, like employees and departments, those would be represented by two separate Models, not one. You want to keep your Models as atomic as possible. A less obvious, but still valid, use of Models is for representing non-permanent pieces of data. For example, if your site has a contact form, that data won’t be needed after it’s emailed out, but must be represented by a Model up until that point (in order to perform validation and so forth). Models not only represent the data, but common manipulations of that data, from validation routines to altering the data (e.g., stripping the HTML tags out of submitted text).

Views are also straightforward when it comes to Web development: Views contain the HTML. Most frameworks I’ve used (I’ve had the most experience with Yii, Zend, and Ruby on Rails), use a page that acts as the primary layout. For example, that page would start and finish the HTML. Other View pages represent aspects of the interface, such as a form, a listing of multiple records, or the display of an individual record. Those individual pieces are then brought into the primary layout file to generate the complete output.

If you have a classic employees-departments application, you might have these View files:

• Primary layout for the employees pages
• Form for adding and updating employees
• Listing of all employees
• Display of all the information for a single employee

There would be complimentary pages for the departments section, too, possibly including a variant on the primary layout that’s particular to the departments area.

Views don’t just contain HTML, however, they must also have some PHP (or whatever language). Such code should only perform very simple tasks, like printing the value of a variable. A common beginner’s mistake is to put too much programming (i.e., logic) into the Views. The goal in a View is to combine the data and the presentation to create the interface. Views shouldn’t be “thinking” much. For example, a View would likely use a conditional so that it only prints a variable if it has a value, or use a loop to print out every member of an array, but a View should not do serious formatting or alterations on the data. Say you have a page that also displays how long the logged-in user has been registered on the site. The original registration date would come from the database (i.e., be part of the Model) and the resulting calculation would be displayed in the View, but the actual calculation should take place in the Model, not the View (or the Controller).

A Controller often acts as the glue between the model and the view, although it’s not always that clear. (In fact, the MVC distinctions can easily be blurred.) As I said, a Controller represents actions: things done with Models and things done with Views. Model actions include the retrieving of a single record from the database or the retrieving of all the records. View actions are responses to user events: the submission of a form, the loading of a page, etc.

To put this all within a context, a user goes to a page like www.example.com/index.php/employee/list (the formatting of URLs is a different, but related subject). This might trigger the “list” action within the employee controller. That list action might invoke a “retrieve all” action, which gets all of the data from the Model. That list Controller action then passes that data to the “list” view, which uses a loop to display all of the employees within the layout of the site.

And that brings me to some actual code, which I’ll show in a subsequent post (hopefully in two days). [intlink id=”505″ type=”post”]EDIT: Here’s the link to part 2![/intlink]