codemusings.com

Model-view-controller (MVC). What is it? What does it do? Is it helpful to web development? All valid questions. And questions this post will try to answer. To learn the Zend Framework it is imperative that you understand the theory behind MVC and how the architecture pattern works.

History ov MVC

The MVC architecture was first described in 1979 by Trygve Reenskaug, who was working on Smalltalk at Xerox Palo Alto Research Center at the time. This was used for a time in desktop GUI applications and has gone through some changes over the years. Microsoft, as usual, took the idea and renamed it Model View Presenter (funny how they tend to do that with everything). Back to MVC though, there has been somewhat of a revival in recent years and it seems to work better in a web application environment.

What is MVC?

A big part of MVC is separating the application into different layers. These layers communicate with each other but at a distance through interfaces. The three layers are easy determine if you read the name, model, view, and controller. Each layer has it’s own place and it’s own function in the application. To understand how this is helpful in a web application let’s first take a look at how web apps, especially PHP based apps, have been or are still written.

Spaghetti code is hard to describe as a design pattern but that is what often happens when no framework is used. You start out with PHP files for each HTML file in a site or perhaps you’ve refactored part of it and some of these PHP files actually control a number of HTML files that are similar (forms perhaps). You’ll see a long list of includes in these files: template library includes (think Smarty), perhaps an include for database connectivity, a config file include that includes various other application configuration options.

Now let’s use this application for a while and make small changes here and implement new features there. It’s happily cruising along and then somebody finds a bug. Now you need to fix the bug but it’s a logic error that is used in a dozen different files and you can’t exactly remember which ones. So you spend hours hunting down all the places where the code appears and changing it. Then the client decides to use a different database on the backend. Now you have to change all the SQL statements for the entire application. If you thought ahead maybe you put all the SQL in one file and that’s all you have to change. If not it will be scattered all over the place in different files. Now the client doesn’t want to pay you for your time anymore because it takes too long to fix anything. Or perhaps it’s an open source project and you start losing developers because nobody wants to work with the mess of code you now have.

This is what your typical PHP application from a few years ago would look like. Then there was a revolution in the PHP community. Object Oriented Programming (OOP) was introduced and with widespread adoption this has changed the way applications were developed. The PHP community started using OOP best practices. This meant that unit testing was now becoming more common. Applications started being developed in more structured format. Then everybody started writing their own frameworks instead of rewriting every application from scratch.

The next major push in web development, not just PHP, was MVC based frameworks. Most modern web frameworks that have a large following are based on the MVC architecture. There is the PHP frameworks like CakePHP, CodeIgniter, Zend Framework, and Symfony. Python has Django. Ruby has Merb and Ruby on Rails. Groovy has Grails. And the list goes on.

The Three Layers of MVC

Let’s take a quick look at the components in an MVC architecture. I’m going to leave the model until last because it is perhaps the most important aspect of this whole idea. If some of these terms sound esoteric don’t be afraid the concept is actually quite simple to grasp. To understand this let’s take a look at a very simple example. And as the say a picture is worth a thousand words. Take a look at the image below.

So we have our view. This is our user interface (UI). In the web app world this is everything the user sees in his/her browser. We’ve all seen this type of view before. A login form. The view layer in our application would contain all the code that is used to display this to the user.

When the user clicks on the “Login” button the controller takes over. The controller’s responsibility is to take the users request from the view (arrow 1), send the request to the model (arrow 2) and then if the model has a response send this back to the view(arrows 3 and 4). Remember that old spaghetti code we talked about earlier. Hopefully you can already start to see a difference.

Then there’s the model. The model should be where all our application logic is. The model is where data persistence is implemented whether it be to a database, a file, or another web service. Let’s look at our example here. The controller sends a request to authenticate this user to the model. The model handles the tasks associated with this. If we are using a database, it will query the database to match the username. If it finds a matching username in the database it will query for the password. If the passwords also match it will inform the controller that the user is authenticated. If either the username or password do not match those in the database it will return a failed authentication response. Depending on the scenario and the requirements of our application the model may also return all the users data to the controller so that it can then send it to the view to be displayed to the user.

This is a very brief overview of MVC. The concepts are not hard to grasp but they are important if you plan on learning the Zend Framework. This is a bit of a longer post but all the ones in this tutorial series will be. This by no means covers everything about MVC. You can find a lot of information that has been written about MVC by doing some searches online. I’ve included some resources for you if you would like to read more on this.

Extra Reading

• Zend Framework: Surviving the Deep End – Chapter 2 This is very Zend Framework centric obviously
• Wikipedia’s MVC Entry
• Sun Java MVC Design Pattern

Related posts:

1. ZF Tutorial 3 – The Model In the last post of this series I covered some...
2. ZF Tutorial 1- Introduction Welcome to the Zend Framework Blog application tutorial series. I’m...

Related posts brought to you by Yet Another Related Posts Plugin.