From Federico Cargnelutti

Contents 1 Introduction 1.1 Three-tier Architecture 1.2 Model-View-Controller Architecture 2 Zend Framework 3 Architecture 3.1 MVC pattern 3.2 Front Controller pattern 4 Coupling 5 Criticism 5.1 Performance 5.2 Design 5.3 Namespaces

Introduction

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.

Architecture

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.

Coupling

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:

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.

Criticism

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.

Performance

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.

Design

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.

Namespaces

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.