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.
13 comments
Comments feed for this article
Trackback link
http://www.otton.org/2008/08/05/frameworks-libraries-php-zend/trackback/
August 10, 2008 at 2:53 am
Pingback from Frameworks vs Libraries « PHP::Impact ( [str Blog] )
August 12, 2008 at 9:33 pm
Pingback from Frameworks vs. Libraries in PHP (why I choose frameworks)
August 15, 2008 at 12:21 pm
Pingback from Ralfs PHP und Zend Framework Blog » Blog Archiv » PHP Frameworks im Vergleich
September 1, 2008 at 11:39 am
Pingback from aur1mas » Blog Archive » Skaitiniai (III)
August 12, 2008 at 11:47 am
phpdummi
If you’re looking for a framework that support most enterprise requirements like PAC a.s.o take a look at http://adventure-php-framework.org/Page/001-Home/~/sites_demosite_biz-action/setLanguage/lang/en !
The page is currently re-designed, so in a week or two it’ll be more user friendly (and more sexy ;).
Of course, if a framework supports most features out-of-the box and comes with a PAC-like architecture it becomes automatically more complex and harder to deal with.
But if you implement features where you need multiple designs for various languages or simply want to reuse your already implemented modules take a look at it.
Questions or suggestions?
Btw: I had to register to post this … not very user-friendly if you ask me ;)
August 12, 2008 at 11:56 am
david
Thanks for the recommendation Alexander - I saw your comment at PHP::Impact, and I’m planning to take a look at APF, although I’m wondering if a PAC/HMVC-styled drop-in for ZF is the most sensible way to go, as it seems to be gaining traction.
I’ve turned off registration now.
August 12, 2008 at 12:34 pm
phpdummi
The problem I ran into at PHP::Impact was, that wordpress doesn’t do any escaping or other stuff to make my posted code available. It simply ripes away the Code …
So if you (or other guys who read this post) have any questions, feel free to ask!
August 12, 2008 at 9:11 pm
austin_web_developer
You have a very interesting take on the library vs Frameworks debate.
Having gone through the same internal debate (in my head) and come out on the side of Frameworks, I will say that giving yourself over to the framework is the hardest thing for a developer to do.
Developers create and design systems. A framework takes away a lot of the design options off the table from the onset, and odds are you’ll love 70 - 85% of the conventions and hate the rest.
Putting yourself in the hands of a system that you don’t 100% agree, is a tough thing to do, but I think the ease with which I can get a web application going + not having to completely re learn my code base after I’ve been away from it for weeks makes frameworks (Cakephp especially) a winner in my book.
Also remember that frameworks usually include libraries (sort of) in the form of gems (Rails) or plugins (Cake). So in a way, you get the best of both worlds … no?
August 12, 2008 at 9:27 pm
Tony Bibbs
How’d PEAR miss any mention in this? Zend Framework is basically PEAR minus the “framework” components PEAR has refused to allow (MVC implementation, etc). Oh, and the fact ZF doesn’t ship anything as individual packages is the real shame. I complain about that every chance I get. Kudos on this post though, people need to get away from the all-or-nothing frameworks out there.
–Tony
August 12, 2008 at 11:31 pm
Stevie Wonders
Ummm. Just picking a nit, but the pic above shows a pozidrive and a flat head. Wouldn’t the caption make more sense if the pic were actually a pozidrive and a phillips?
August 12, 2008 at 11:33 pm
Stevie Wonders
Oops, sorry for the extra post. I meant to mention that I enjoyed the article. I’m currently in that mode mentioned by austin_web_developer above. So this helped me out.
August 13, 2008 at 1:07 am
Alan Pinstein
I agree very much with the tradeoffs presented in this article. We had a similar conversation last year at the Atlanta PHP users group.
The fact that many frameworks solve simple problems but then you are very stuck if the framework hasn’t contemplated your particular need was a fact I wasn’t willing to live with. However, having used the Cocoa API for Mac development, I was also sure that I wanted a framework to vastly improve development time and reduce the amount of code that needs to be written and maintained.
I ended up writing my own framework called PHOCOA, which is open-sourced (http://phocoa.com). I tried very hard to minimize the dependencies and keep things very loosely coupled.
For instance, we use Propel as the ORM. However, there is almost no coupling between the framework and Propel, other than the initial bootstrapping and of course the code-gen system. It is all done via interfaces such as Key-Value Coding that allows the framework to talk to the object model without knowing how it works. This level of indirection would allow you to easily write your own back-end or use another back-end without having to re-write the higher-level parts of code.
Everyone of course has their opinion, but after years of working with “library only” and “full stack frameworks”, I tend to prefer frameworks if they are well-written. Just my 2 cents…
August 13, 2008 at 2:08 am
ikhsan
PHP is my first server script that i have learned, starting with hardcoding until the application code looked like spagheti inside….very messy. So i learn about framework, application architecture, application design, postnuke, joomla, drupal, the last is cakePHP. Once i and some of my friend created a PHP Framework specialized for creating single screen web application using AJAX, and now still underconstruction.
http://sourceforge.net/projects/cdmx/
After some years experience with PHP i try to using ruby, but i don’t know i don’t like it at all. Until now i really think that we can’t simplify the solutions….it’s never happen one solution for all, besides i think software is combination between engineering and art.
Its true and abolutely agree the framework is exist for make easier to develop application, but in fact the problems is very dynamic. PHP with his silly programming conventions is giving the flexibility to us to provide an idea for some problem, so why i don’t like ruby that tried to ‘bridle’ the creativity some ‘crazy’ programmer.