1. Support for multiple types of clients
2. Reduce duplicate code when supporting multiple types of clients
3. Isolating domain logic from the user interface

Note that items 2 and 3 are both dependent on item 1. Support for multiple types of clients is the single driving force behind the MVC design pattern. Following are some examples of client types:

• Web Browsers
• API Clients
• Admin Processes (e.g. CLI, cron, daemon)
• Unit Tests
• Native GUI

Realistically, how many of these different client types do you need to support? If you’re taking a RESTful approach, then Web Browsers and API Clients can be combined into one type of client, which we can just call User Agents. Likely you’re not building a Native GUI. This leaves you with the following three types of clients to support:

• User Agents
• Admin Processes
• Unit Tests

Do you really need to use the MVC design pattern in order to support User Agents, Admin Processes, and Unit Tests? Likely not. That’s not to say that there aren’t benefits to isolating domain logic from the user interface. However, if you don’t need to support multiple types of clients you should really question your use of the MVC design pattern. There are many approaches one can take to separating the domain logic and the user interface, of which MVC is just one.

This bring me to The MVC Paradox. Modern MVC web frameworks inadvertently encourage the coupling of domain logic and user interface. If you don’t need to support multiple types of clients, then decoupling the domain logic from the user interface is the only reason left to use the MVC design pattern.

Modern MVC web frameworks often involve a lot of boilerplate code just to support the primary client type of User Agents. This boilerplate code typically does little to help with supporting the other client types of Admin Processes and Unit Tests. As a result of the overhead introduced by this extra boilerplate code, developers often find themselves creating Fat Controllers (a side-effect of The MVC Paradox). Controllers take on too many responsibilities, both vertically and horizontally. Vertically, Controllers start to handle domain logic that should be pushed down to the Model layer. Horizontally, multiple concerns get stuffed into a handful of Controllers. These different horizontal concerns should be separated out into multiple Controllers (the Single Responsibility Principle). The overhead introduced by modern MVC web frameworks leads directly to these problems.

In contrast, take a look at the Slim PHP 5 micro framework. While not a completely RESTful framework, it does a pretty good job of addressing the concerns I’ve laid out in this post. Here is the “Hello world” example from Slim’s homepage:

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

There is very little boilerplate code involved in handling a User Agent’s request. Minting and handling new routes is incredibly simple. Placing your entire front-end application layer in one file may seem absurd at first. However, it has the nice side-effect of making it painfully obvious if you start to handle domain logic outside of your Model layer or if one route is doing too many things. If your front-end application is large enough, then you can organize your routes into separate files.

This post is not intended to discourage you from using an MVC web framework. There are certainly times when such a framework is useful. As with any technology decision, carefully consider what problem you’re trying to solve and what technology will best address your problem set. Sometimes your technology choice can undermine the very purpose of using that technology in the first place, as is the case with The MVC Paradox.

We’re a new startup with some venture backing. We’re looking to add an experienced developer to help us out for the next five weeks (and possibly more). Qualifications are:

• experienced PHP hacker (5+ years)
• full understanding of MVC frameworks (codeignitor, cake, symfony, zend, kohana or the like)
• comfortable with the LAMP stack
• understanding of git
• able to plug into a new project and start coding in under a day

You’ll be working with a team of 6 developers in downtown Burlington.

Kohort was featured in TechCrunch the other day for raising a “seed” round of $3 million. If you’re interested, contact Steve Blood. You can find Steve’s email address in this thread, or let me know and I can put you in touch with him.

Zend Framework is a free/open source web application framework. It can be used either as a component library or as a full-stack Model–View–Controller (MVC) framework. As compared to its 1.x counterparts, Zend Framework 2.0 is easier to learn, trivially simple to extend, and more performant. It is also easier to use just specific parts of the framework as needed. We will explore the many features of Zend Framework 2.0 including its tooling, functional testing, form, database, pagination, date, markup, navigation, and MVC components. Zend Framework 2.0 takes advantages of several new features in PHP 5.3 including closures/lambdas, namespaces, and late static binding. We will explore some of these new features to understand why PHP 5.3 is a requirement for Zend Framework 2.0 and how you can leverage these new features within your application itself. An example web application will be provided that you can use as a reference when building your own Zend Framework web application.

For those wondering, Zend Framework 2.0 is not out yet but SXSW is not until next March and Zend Framework 2.0 will most likely be released by then. The description above is based on the Zend Framework 2.0 Requirements and discussions on the Zend Framework contributors mailing list.

Model

Your domain objects. There is no Zend_Model since your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).

See example Models in application/models/

View

The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of .phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).

See example Views in application/views/

Controller

Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.

See example Controllers in application/controllers/

By default, Zend Framework will route requests based on URI segments as follows:

:controller/:action[/:key/:value]

A few example URIs:

• foo/bar (foo controller, bar action)
• foo/bar/baz/shaz (foo controller, bar action, baz=shaz)

It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.

In my next post in this series I plan on taking a slight detour so that we can explore a very useful component, Zend_Layout.