There's No M in Zend

Zend are the company behind the development of PHP itself, as well as a lot of professional PHP tools, such as the Zend Optimiser, which optimises and caches code (as the name implies). So it was with a bit of enthusiasm that I read the news that Zend Framework 1.0.0 had been released. I've been looking around for a decent PHP framework for a while now, and eventually settled on writing one myself. There are pros and cons to each way of working – with your own code, you can leave out the irrelevant parts, and write something that makes sense to you and operates as you wish. But on the flip side, you can't beat the polish and sheer size of a community-built framework.

Zend Framework promises:

• A modular structure – only use what you need
• A full MVC framework
• considerable extensibility
• A sprawling mass of modules covering everything from authentication to a built in Amazon Services API.

It was the modular nature of Zend that made me prick up my ears. As far as frameworks go, I'm more in favour of those that offer less 'magic' in their functionality. CakePHP, for example, does a lot of the work for you by generating magic data accessor methods, and can even create 'scaffolding' which implements a CRUD frontend for your tables. I didn't like the way it forced you to name methods and database tables for it to work, though, and ended up writing a framework which uses extended data objects in a way that makes more sense to me. (Interestingly, Jonathan Snook reviewed Zend Framework also but liked CakePHP's automation more.)

But back to the Zend Framework. Aside from some core modules, Zend lets you only use the modules you need, although it does provide an MVC framework which I imagine most people would use. It is the MVC implementation that irked me the most about Zend.

Learning UI design at uni (in Java no less – it really made me appreciate the Visual Studio IDE), MVC structure was driven into us quite thoroughly. Models were for data, views represented the user interface, and controllers handled the business logic. And in an ideal system, there wouldn't be any overlap. Most of my apps aren't quite that perfect, but I like to work towards that idea.

Zend Framework, though, seems to be a little confused as to how MVC should work. It's very big on controllers, to the expense of the models, and views to a lesser extent. Controllers in the Zend world handle nearly all of the logic, including SQL queries and data manipulation. In my eyes, this is bad form. Data manipulation should be handled by data objects (the model). But there doesn't appear to be a model in Zend's idea of MVC.

And when it comes time to display something to the user, there is very little that can be done to the view. What about presentation logic? I understand the idea of keeping all PHP out of the view, but personally I'm not adverse to a foreach loop for each of my items, for example. However it seems this is frowned upon in ZF. And the idea of 'partials', or pieces of a page that can be rendered into the page, is also missing. It looks like implementing common sections across different views is a clumsy process.

I really wanted to like Zend Framework. It has many useful modules, and is undoubtedly better written that my little framework. But its flaws irk me, so for now I'll wait. Perhaps the next release will be truly MVC.

To top