Design Patterns, Frameworks, PHP, Programming, Software Architecture

Zend Framework Architecture


Before we begin our exploration of the architecture of the Zend Framework (ZF), it is important to discuss how a typical MVC application is built. Examining and understanding the architecture of an MVC Web application allows you to make more contextually sound choices when building your application.

Three-tier Architecture

The three-tier architecture focuses on defining responsibilities between different parts of the application. It has the following tiers:

Presentation Tier
The top-most level of the application is the UI. The main function of the interface is to translate tasks and results to something the user can understand.

Application Tier
This layer coordinates the application, processes commands, makes logical decisions and evaluations, and performs calculations. It also moves processes data between the two surrounding layers.

Data Tier
Here information is stored and retrieved from a database or file system. The information is then passed back to the logic tier for processing, and then eventually back to the user.

Model-View-Controller Architecture

Although the three-tiers is similar to the MVC architecture, they are different. Conceptually the three-tier architecture is linear. The Presentation tier never communicates directly with the data tier and all communication must pass through the Application tier. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.

Zend Framework

Zend Framework provides components for the MVC and Table Gateway design patterns which are used in most Web applications. Developed by Zend Technologies and released in 2005, Zend Framework is heavily based on the Solar Framework, developed by Paul M. Jones, reason why they share a similar underlying architecture.

There are 3 types of Web application frameworks:

  1. The ones that offer a solid infrastructure: Symfony, Solar, Ruby on Rails and Django.
  2. The ones that offer a component library: ezComponents and PEAR.
  3. The ones that offer both: Zend Framework.

Zend Framework not only offers a solid infrastructure, but also an extensive component library. The component structure of ZF is somewhat unique, each component is designed with few dependencies on other components. This loosely-coupled architecture allows developers to use components individually.


The framework architecture is based on the Front Controller and Model-View-Controller architectural patterns:

MVC pattern

The Model is the part of the application that defines its basic functionality behind a set of abstractions. The data access layer and some business logic is defined in the Model. The Views define exactly what is presented to the user. Usually controllers pass data to each view to render in some format. The Controllers bind the whole pattern together. They may 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.

Front Controller pattern

Zend_Controller is the heart of Zend Framework’s MVC system. Zend_Controller_Front implements a Front Controller pattern, in which all requests are intercepted by the front controller and dispatched to individual Action Controllers based on the URL requested.


ZF provides a loosely-coupled component library simplified to provide most of the functionality everyone needs to develop Web applications. In object-oriented programming coupling or dependency is the degree to which each component relies on each one of the other components. The biggest advantage of a loosely-coupled architecture is that it allows developers to use components individually.

Neil Garb did an excellent job measuring the level of coupling in the Zend Framework based on the number of dependencies set in code. I’ve extended his work by measuring the level of coupling between components set at runtime. I’m using the Inclued extension to trace through the hierarchy of file inclusions and class inheritance at runtime.

The following diagrams where generated using Graphviz:

Zend_Controller dependencies

Zend_Controller and Zend_Db dependencies

Zend_Controller, Zend_Db and Zend_From dependencies

A standard Zend Framework application requires the following components: Zend_Controller, Zend_Uri, Zend_Registry, Zend_Loader, Zend_Config, Zend_Layout, Zend_View, Zend_Filter, Zend_Validate, Zend_Db, Zend_Form and Zend_Exception.


Zend Framework is intended to serve as a novel way to manage Web development complexity. Many consider ZF to deliver reasonably well on this promise, however, it does not universally accommodate all design styles, environments or requirements.


The performance of a framework is influenced by many factors, particularly the configuration of your servers. However, the design of an application can make a big difference and determine whether your site is slow or highly responsive. Recent benchmarks show that the Zend Framework is slower than other Web frameworks.

Although low coupling is a sign of a well-structured system, it may reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Regardless, in many modern frameworks, the cost of reduced performance is often seen as a worthy trade for the benefits to the software development process that result from low coupling.


Although the framework supports modularity, it lacks of some basic features, such as a Module Coordinator. The system doesn’t include any component or configuration mechanism to deal with Model and Controller dependencies, making it very difficult to share modules between applications. Also, Zend_Controller doesn’t allow modular systems to load model files from within its own module as well as outside modules.

The system lacks of local containers to manage object dependencies and interrelationships. Instead, it uses a global container to store objects. According to Troels Knak-Nielsen, the problem with this is that a global container, whether primitive or sophisticated, will always be a global symbol. Most programmers will agree that global variables are bad design, and that goes for a global containers as well.


With PHP 5.3 coming up on the horizon, the Zend Framework API faces a re-design. While namespaces will hopefully lead to more readable code, Zend developers will finally need to start thinking about some standards for abstract classes and interfaces.


16 thoughts on “Zend Framework Architecture

  1. Pingback: Karl Katzke
  2. Excellent post Federico. How does the inclued library work? Or where can I find more info about it?


  3. You mention that the global container Zend_Registry goes against design philosophy… Are you also recommending we use Zend_Registry as little as possible, in anticipation of the PHP 5.3 improvements?

  4. Using Zend_Registry has its consequences, for example, you need to understand the whole system to be able to modify or replace a single component and also, you have to predict the long term requirements of the system. Cake and CodeIgniter are great examples of highly-coupled frameworks. Zend Framework, on the other hand, is loosely-coupled.

    If you want to reduce coupling between components, I’d recommend using a local container. That’s why I think Zend_Container is the one to watch. The purpose of this component is to replace the use of singletons and Zend_Registry. More info here.

  5. Great post, Federico!

    RE: A standard Zend Framework application requires the following components: Zend_Controller, Zend_Uri, Zend_Registry, Zend_Loader, Zend_Config, Zend_Layout, Zend_View, Zend_Filter, Zend_Validate, Zend_Db, Zend_Form, Zend_Paginator and Zend_Exception.

    I find it hard to believe that a standard ZF app requires Zend_Paginator, since it won’t be released until 1.6. ;)

    The Zend_Container proposal is very interesting, as was yours. We’ll be watching this proposal closely to see if the community can come to a consensus on the value and required complexity of such a DI container.

    BTW, it’s all but decided that Zend’s contributions to 1.7 will be primarily- if not exclusively- performance fixes. Well, performance fixes and more development of Zend_Tool. :) I know that performance testing and optimization is a big investment and is very important to ZF’ers, so I think it will give the Zend-employed ZF’ers a good chance to evaluate key components very closely with no functionality/optimization effort tradeoffs before them.

    Of course, namespace support is a likely feature in ZF 2.0, but I can tell you it will be at least a few months before we start the 2.0 discussions in earnest.


  6. Pingback: GrantPalin
  7. ZF performance has pretty much gone done every performance release.. Its gone from being one of the fastest out there where I was really interested in it to one of the slowest. One of the things that killed my interest every time I brought performance up it got blown off.

    It was always features first performance later, but its a chicken and the egg issue and you can’t deal fully with one without thinking of the other.

  8. Pingback: Top Posts 2008
  9. Very good summary of Zend Framework.

    If i could add something i would say that Zend Framework is probably still the nicest components library for php (considering its size).

    On the other hand it lacks interfaces, uses way too many static calls and has bloated APIs. Some of the components would benefit from breaking them down into smaller units with simple responsibility.

    All very good points especially on lack of dependency management.

  10. Nice post. Like the graphs and wanted to generate them for my own application built on top of zend. Do you have a script to do this?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s