usability

Phillips and Pozidriv aren't synonyms

We all know that loose coupling is good and tight coupling is bad, so why, over the past couple of years, has the web industry gone nuts for tightly-coupled frameworks?

Since the publication of Pragmatic’s Ruby on Rails book, the industry has fallen in love with frameworks. Because Rails wrapped up several perfectly sound techniques in one easy-to-use package, people who learnt it were, almost incidentally, learning a solid web development pattern. Add a dash of silver bullet marketing, and its no surprise many of them rushed to re-implement it in their native languages. PHP in particular has spawned a ridiculous number of variations on the theme.

But the problem with RoR-derived frameworks is that, once you get past the trivial use-cases, the interdependency of the framework components and the “one-size-fits-all” ethos means you end up fighting your own tools for supremacy.

I and a couple of other developers started looking seriously at PHP frameworks last year. I was badly burnt by some legacy Smarty code four or five years ago, so although I saw the advantages of enforcing consistency and separation of concerns across a group of developers with wildly different styles, I was cheerleader for the most lightweight option – CodeIgniter.

Between us we examined CodeIgniter, Symfony and CakePHP. After prodding them for a while, we concluded that none of them were right for us – CodeIgniter was too primitive (for example it relied on an output buffering hack to embed views within views), Symfony was over-engineered, and CakePHP had poor documentation and slavishly followed some of RoRs… dumber conventions.

We originally discounted Zend Framework because it was in a pretty primitive state when we started our research. However when we went back to take another look, we realised that even in its pre-1.5 state it had some potentially very useful components. Its key virtue for us was that, despite the name, it was very clearly a loosely-coupled library rather than a tightly-coupled framework (you can get a feel for this by viewing Federico Cargnelutti’s dependency graphs for some common PHP tools).

Zend’s orthogonal design allowed us to make use of individual components without dragging the entire framework along too. Attempting to decouple most frameworks requires major surgery – to take CodeIgniter as an example, its file-backed Config class is loaded automatically by the framework; if you prefer to store config settings in some other backing store, you’re out of luck. With Zend however, its painless – not only can you back Zend_Config with any data store you want, you can abandon it entirely because none of the other components rely on it. This also gives Zend a much gentler learning curve, allowing us to get our (and other peoples’) heads round it at our own pace, without committing ourselves to building an entire commercial project on top of an unknown quantity.

With Zend you can still take advantage of some very high-level components (eg routing, ACL), but if you want to, say, dump the Table Data Gateway-inspired DB classes in favour of PDO, nothing breaks. There’s little inter-dependancy between the components. If you abandon large parts of the framework, you can even get away with replacing the whole MVC architecture with something a bit more sensible like PAC. (The new Zend_Layout component supports two-step rendering, which alleviates many of the problems with MVC, but it’s hardly an ideal solution).

In summary, if you’re searching for a framework for a non-trivial PHP project, or one that you can slowly incorporate into your existing style, please take a careful look at Zend. There are still some problems (eg the use of TDG instead of Active Record), but the loose coupling means you can avoid them most of the time.

Update: Brian recommends Kohana as a PHP5 version of CodeIgniter, with improved architecture.