The MVC Paradox

Use of the Model View Controller (MVC) design pattern is generally accepted as a best practice in modern web applications. Like all design patterns, MVC is a reusable solution to a common problem. The MVC pattern is intended to address the following concerns:

  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:

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

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.

Update (12/10/2012): This blog post has been translated into Serbo-Croatian by Jovana Milutinovich of

Boston PHP Northeast Conference Call for Papers Closing!

The Boston PHP Northeast Conference’s Call for Papers will be closing on Thursday, April 12th so be sure to get your talk submissions in before then! The conference will be taking place on Saturday, August 11th and Sunday, August 12th at Microsoft’s NERD Center in Cambridge, MA and will be focused around four tracks:

  • Core PHP
  • Web Development
  • Training
  • User Experience (UX)

Boston PHP will be hosting the event in partnership with other northeast regional user groups including the Burlington, Vermont PHP Users Group (which I organize) and the Atlantic Canadian PHP User Group. If you have any questions or are interested in sponsoring then please send a message to Boston PHP.

The Future of CouchDB and Couchbase Server

What’s the future of CouchDB? It’s Couchbase.” —Damien Katz

The future of CouchDB is CouchDB.” —Noah Slater

First of all, don’t panic. The Apache CouchDB project is thriving. There are plenty of core contributors who are dedicated to the project. If you’re using CouchDB, you’re fine. If you’re considering using CouchDB, you’ll be fine. CouchDB has a bright future ahead of it. Couchbase has repeatedly said that they’re not the CouchDB company, so this shouldn’t be a surprise to anyone.

My interpretation of this announcement is that CouchDB is forking. Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

CouchDB has two futures: CouchDB and Couchbase Server. Traditionally, forking a project in this manner has been considered a Bad Thing. From The Jargon File entry for forked:

An open-source software project is said to have forked or be forked when the project group fissions into two or more parts pursuing separate lines of development (or, less commonly, when a third party unconnected to the project group begins its own line of development). Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.

In my humble opinion, forking should no longer be considered a Bad Thing. Distributed revision control systems, such as Git, have made it much easier to merge changes back-and-forth between forked projects. If an individual or organization wants to take a project in a different direction, great! It sounds like Couchbase Server will be designed to meet a set of needs that are not being met by CouchDB. If so, a fork is perfectly appropriate as now both sets of needs can be met.

Top Five Posts of 2011

Continuing a trend started by Cal Evans and then followed by Chris Cornutt, Matthew Turland, and Joe Devon; here are the top five most viewed posts from my blog in 2011.

5. CouchDB and Domain-Driven Design

This post covered two topics that are of great interest to me. Document databases like CouchDB have much potential when it comes to domain-driven design. The post outlined some techniques for serializing domain objects into CouchDB documents.

4. Addressing the NoSQL Criticism

I heard a lot of NoSQL bashing this year at OSCON. As a result, I decided to write a rebuttal to many of the criticisms that I heard. This post inspired a lively comment thread.

3. Testing PHP 5.4

This was a short post on how to help the PHP Quality Assurance Team by running the tests for the latest development version of PHP 5.4. It covered downloading, compiling, and running the tests. Most importantly, it also covered reporting your test results.

2. Exploring RabbitMQ and PHP

I was exploring the possibility of using RabbitMQ for an upcoming project. I decided to post some notes on my experience getting started with RabbitMQ and integrating it with PHP. I haven’t ended up using RabbitMQ in production yet, but I’m confident that I’ll end up using it at some point.

1. CouchDB jQuery Plugin Reference

I had been frustrated by the lack of documentation for the CouchDB jQuery plugin—so decided to write my own. After I wrote the blog post, Max Ogden pointed me to Dale Harvey‘s documentation generator for jquery.couch.js and a copy of the generated jQuery CouchDB documentation. Max and Dale are also working on a more flexible jquery.couch2.js.

Boston PHP Northeast Conference

I’m excited to be able to announce that the first ever Boston PHP Northeast Conference will be taking place on Saturday, August 11th and Sunday, August 12th at Microsoft’s NERD Center in Cambridge, MA. This regional event is intended for PHP beginners, enthusiasts, and professionals alike. The current plan is to have four tracks:

  • Core PHP
  • Web Development
  • Training
  • User Experience (UX)

Boston PHP will be hosting the event in partnership with other northeast regional user groups including the Burlington, Vermont PHP Users Group (which I organize) and the Atlantic Canadian PHP User Group. We’re still early in the planning stages, so there will be more details to come later. If you’re interested in speaking, have ideas for the event, or are interested in sponsoring then please send a message to Boston PHP.

The Twelve-Factor App Applied to PHP

If you develop web apps, I encourage you to check out The Twelve-Factor App. This is an excellent resource for anyone building and deploying software-as-a-service. PHP has great support for many of the twelve-factors. I want to take a look at specifically how each factor may be applied to a PHP application.

I. Codebase

“One codebase tracked in revision control, many deploys”

There’s really not much here that would be different in PHP versus any other language. Who isn’t using some form of revision control these days?

II. Dependencies

“Explicitly declare and isolate dependencies”

There are a few tools available to PHP developers to help manage dependencies. The PEAR package manager may help here, but has its flaws. Pyrus, the PEAR2 package manager, looks promising. There’s also Composer. I’ve heard of people using their operating system’s package manager (e.g. RPM) to deploy their PHP applications and manage dependencies. I’m not sure if there any tools in PHP to enforce dependency isolation.

III. Config

“Store config in the environment”

The simplest option here is to use environment variables. Many frameworks, including Zend Framework, allow you to have environment-specific configuration such as development, test, and production. This is not recommended for twelve-factor apps as it doesn’t scale as new environments are added.

IV. Backing Services

“Treat backing services as attached resources”

There’s not really anything to say here that’s specific to PHP.

V. Build, release, run

“Strictly separate build and run stages”

Phing or the more general-purpose Ant could work here. Even though it’s not written in PHP, there’s no reason why you couldn’t use Capistrano for this. I don’t think the run stage typically applies to PHP, as it happens implicitly as part of the release stage. However, there are tasks such as flushing the APC cache (if apc.stat=0) that might be considered part of the run stage.

VI. Processes

“Execute the app as one or more stateless processes”

PHP processes are already stateless and shared-nothing. This makes PHP a great fit for twelve-factor apps. Memory space or the filesystem should be used as a short-lived, single-process cache. If you’re using an asset manager, such as Assetic, then any assets should be compiled and cached during the build stage.

VII. Port binding

“Export services via port binding”

I don’t think port binding applies to PHP applications—at least not in the way it’s meant in twelve-factor. PHP relies on a web server and uses something like FastCGI or PHP-FPM to communicate with the web server. PHP 5.4 will have its own built-in web server, but this is intended for development use only. It’s really the combination of PHP and its web server that will be bound to a port. This brings up challenges when it comes to dependency management, as the web server itself is now a dependency.

VIII. Concurrency

“Scale out via the process model”

I’m not sure how processes would become first-class citizens in a PHP web application. However, each individual request/response cycle is handled by its own process. In that regard, PHP already uses the process model.

IX. Disposability

“Maximize robustness with fast startup and graceful shutdown”

PHP processes are very disposable. Again, this is just part of how PHP works.

X. Dev/prod parity

“Keep development, staging, and production as similar as possible”

Nothing specific to PHP here. Although, it’s not uncommon for PHP developers to use SQLite in development and MySQL or PostgreSQL in production. This is not recommended for a twelve-factor app—use the same software and versions of backing services in all environments.

XI. Logs

“Treat logs as event streams”

There are tons of logging options in PHP. Zend_Log_Writer_Stream lets you send log data to a PHP stream. Alternatively, StatsD and the PHP StatsD library look pretty good.

XII. Admin processes

“Run admin/management tasks as one-off processes”

This is easy enough in PHP. If you want an interactive shell with readline history, tab completion, and quick access to documentation then check out phpsh.

CouchApps at CouchConf NYC

Here are the slides from Monday’s CouchConf NYC session on CouchApps with CouchDB, JavaScript and HTML5:

Domain-Driven Design at ZendCon 2011 UnCon

Here are the slides from today’s ZendCon UnCon session on Domain-Driven Design:

If you were in this session, please give me feedback on

Learning CouchDB at ZendCon 2011

Here are the slides from today’s ZendCon tutorial on Learning CouchDB:

You can instead download the PDF version, if you’d prefer.

If you were in this session, please give me feedback on

Burlington Telecom Advisory Committee

This past Monday evening I was appointed by the City Council of the City of Burlington, Vermont to the Telecommunications Advisory Committee. In this volunteer position, my role is to advise the City Council on matters related to Burlington Telecom, a municipally owned telecommunications services provider.

I have many of my own opinions about Burlington Telecom, its role in our community, and its future. As a member of this committee, I’m more interested in bringing the opinions of others forward. If you’re part of the Burlington community, please share with me your thoughts about Burlington Telecom. What do you want out of Burlington Telecom? What attributes of Burlington Telecom are important to you? Please share these thoughts publicly on Google Moderator. I’ve shared a few of my own thoughts to get things started.

As I mentioned, I have my own opinions about Burlington Telecom. To understand further where I’m coming from, I’ve included here a truncated version of the letter I sent applying to be on the committee.

Dear City Councilors:

Enclosed for your consideration is my application to join the Burlington Telecom Advisory Committee. I was one of the first beta customers when Burlington Telecom launched. I am now both a residential and a business customer. I was enthusiastic about the vision for Burlington Telecom from the moment I first heard about it. As someone who spends a good portion of his personal and professional life online, I understood immediately the cultural and economic benefits that an advanced fiber optic network could bring to our city.

Burlington Telecom is the 21st century equivalent of rural electrification, at a local scale. Like electricity in the 1930s, private companies are unwilling to invest in a telecommunications infrastructure that will spur economic growth in less populated areas. Companies like Verizon have gone so far as to divest their networks in non-metropolitan areas so that they don’t need to build-out modern broadband infrastructure in these places.

The Burlington Electric Department proudly states, “public power since 1905.” The City of Burlington created the Burlington Electric Department a full 30 years before the forming of the Rural Electrification Administration at the federal level. The City of Burlington seemed to have similar foresight when they created Burlington Telecom. Perhaps Burlington Telecom is an idea that is ahead of its time. Maybe we should wait several decades for a national initiative on telecommunications infrastructure. Alternatively, we can be proud of what has been done with Burlington Telecom. There are serious challenges to maintaining Burlington Telecom as a public resource, but these are challenges worth addressing.

Like the Burlington Electric Department, I believe that the people of Burlington can again be proud of Burlington Telecom. During Tropical Storm Irene, my house lost power for only 30 minutes. This was a point of civic pride for me and provided an exemplar of how our public utilities can be operated. Burlington taxpayers have regularly voted to fund Burlington Electric Department initiatives around green energy, energy efficiency, and general infrastructure improvement. If people can be proud of things as intrinsically boring as utilities and electricity, then we can be proud of a state-of-the-art fiber optic network that provides high-speed Internet, television, and telephone services.

As a member of the Burlington Telecom Advisory Committee, I hope to understand more fully the challenges facing Burlington Telecom and advise the City Council on addressing these challenges while maintaining Burlington Telecom as the vital public resource that it is. I am an advocate for a vision of Burlington Telecom not as a burden, but as a source of great opportunity for our city.