MVC in Zend Framework

In this post I’ll try to explain the implementation of MVC (Model-View-Controller) in the Zend Framework. If you are not familiar with Zend Framework, you might read the Introduction to Zend Framework post

I assume you already know the idea behind the Model-View-Controller idea. If not please read the section below – or the MVC section on this page

MVC Quick-Start

In short Model-View-Controller comes down to this:

  • Model – This is the part of your application that defines its basic functionality behind a set of abstractions. Data access routines and some business logic can be defined in the model.
  • View – Views define exactly what is presented to the user. Usually controllers pass data to each view to render in some format. Views will often collect data from the user, as well. This is where you’re likely to find HTML markup in your MVC applications.
  • Controller – Controllers bind the whole pattern together. They manipulate models, decide which view to display based on the user’s request and other factors, pass along the data that each view will need, or hand off control to another controller entirely. Most MVC experts recommend » keeping controllers as skinny as possible.


Zend Framework is not only using the MVC design pattern, but it’s also using the Frontcontroller design pattern.

The Frontcontroller design pattern requires that all requests are processed through one file – which is a very common practice in a lot of open source webapplications (like Drupal, Typo3, etc.). In most webapplications this is done by using the mod_rewrite module (or similar) to rewrite everything to a file called index.php. One big advantage of this design pattern is that for example, Authorization can be easily implemented into the system.

In Zend Framework this index.php takes care that the Frontcontroller is being instantiated.

Actions and controllers

Using only one controller (the Frontcontroller) would result in large unmaintainable mess with too many methods.

That’s why we use multiple controllers in Zend Framework to split up the different parts of the application, each in its own controller. For example if you want to build a blog, you might build a BlogPostController where all functionality related to blogposts resides. Every task like creating, deleting or modifying a blogpost is called an action in Zend Framework.

To return to our example of a BlogPostController, that controller will look like this:



class BlogPostController extends Zend_Controller_Action {

// method that takes care of creating a blogpost
public function createAction() { }

// method that takes care of modifying a blogpost
public function editAction() { }

// method that takes care of deleting a blogpost
public function deleteAction() { }

// method that takes care of listing blogposts
public function listAction() { }



Routing and dispatching

In Zend Framework each action has its own URL. Through the naming convention of controllerclasses and actions, Zend Framework is capable of translating an URL to the corresponding controllerclass and action. The translation process from URL to Controller/Action is called Routing. The process that calls the specific controller and action, based on the translated request by the router, is called dispatching.

The request-object ( translated request from the router ) is being passed to the controller from the dispatcher. This request-object is being instantiated by the Frontcontroller, being passed to the router class to be filled with request information and at last being passed from the dispatcher to the corresponding controller.

Below you will find an image that shows the total ZF MVC process.


I will write a dedicated post about views in Zend Framework, you will find this later on.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *