Sometimes you make a blog post that generates a lot of feedback. In this case, Nate from CakePHP had a vigorous conversation with me via IM about my blog posting about frameworks. In a nutshell, Nate took issue with my comment that CakePHP isn’t quite there yet because you can’t use components from it outside the framework itself.
Nate does have a point here. Zend Framework is perhaps being *overly* ambitious by not only providing an MVC component, but you can use parts of it outside that MVC component as long as you place the Zend Framework itself in your path. So is Zend Framework truly a framework? Yes, as long as you understand that a web application framework means more than just a MVC-based framework.
At this point, CakePHP is an MVC-based framework only. That is changing (remember my interactive console project?), but Nate’s argument was that perhaps Zend Framework is unfocused and should be concentrating on the MVC part of the web application problem. Not to mention the fact that it still doesn’t have an Active Record implementation for database access. This particular thing baffles me, but what can you do? Zend_Db_ActiveRecord (or whatever you could call it) wasn’t a priority among the core developers for Zend Framework. I still can’t believe that I have to write SQL by hand with Zend Framework, when I have all those magic methods available to me in CakePHP.
Which brings me around to another point. A disproportionately large number of successful open-source projects are the creation of one, very talented, egomaniacal developer. David Heinemeier Hansson is a great developer (and has a big ego from what I’ve seen, heard and read about him) and still is one of the main driving forces behind Ruby on Rails. Without him being there at the beginning, deciding on the core features and rejecting anything he didn’t like, who knows how Rails would’ve ended up? One of the toughest things to do is to say “no” to someone when they ask you for something. Not many people can do it. It’s an especially important skill to have as a developer, because adding in features when they don’t really add anything of value is the kiss of death for an application
So, as a result of this sort of “cult of personality” that surrounds open source projects (or any popular project) you get people initially choosing projects based on the recommendations of others, not on the merits of the project itself. Why pick Zend Framework? It’s rich in libraries, backed by a large well-known company in the industry, and has many talented contributors (including yours truly). But *why* use it for your particular project? Biggest flaw right now as I can see it is (beating a dead horse here today) lack of an ORM database wrapper. Again, CakePHP has one so it can’t be *that* hard to implement such a thing. I know that Davey Shafik has created such a beast for Zend Framework…but it’s nowhere to be seen in ZF 0.91 beta and likely ZF 1.0. C’mon, cut Davey a break and ram it in there.
So, at this point, CakePHP is probably better suited for building an MVC application, despite the lack of libraries that Zend Framework provides that CakePHP does not. On the other hand, a decent programmer should be able to quickly implement such things themselves, right? So, for MVC-based apps that I need to build in a hurry I’m going to pick CakePHP.
There, Nate. You happy now?
[...] Read more @TheKeyboard :: More Framework Fun [...]
Ah, Chris, I always enjoy our conversations.
Sorry if I sounded defensive, I didn’t mean to at all. Actually, you’re one of the few people who I’m able to respect regardless of the level of divergence of our opinions. 
heheh
Anyway, the response I was going to write turned into it’s own post behind my back, and without asking me, so go read it and let me know what you think.
http://cake.insertdesignhere.com/posts/view/18
I think you have missed the point of the framework. Why are you linking the requirement of a mature MVC to a framework. Although I agree that the Zend Framework is not anywhere near as complete as Cake’s I do not think you can make a comparison based upon this.
For advanced projects you generally extend any MVC framework and Zend has allowed for extensive customisation via routes. It does have issues regarding common components which the helper functions try to solve but currently do not.
The strength within the Zend framework is its breadth of coverage, I have found Zend_ACL & Zend_Cache both extremely powerful when extended. I have a short post that covers making a GUI for some of the Zend Framework components.
I really value your conversation with Nate. I’m in the process of evaluating frameworks to try to move a small team toward framework-based PHP development, and your explanations are very helpful. We’re leaning heavily toward Cake, but I want to give a couple of others a fair chance too. The issue of integrating new MVC development with legacy code and a third-party CMS is important to us, so I value your thoughts on using Cake outside of the MVC context.
@Philip
The ability to integrate CakePHP with a legacy app is in direct proportion to how much control over the whole request cycle your legacy app has. It’s quite easy to use 3rd party libraries with Cake by dropping them into the vendor’s directory.
I do know that there is an internal project at work that calls some Cake stuff via a cron job. I will investigate that and see what the heck is going on there.
Zand Framework has an implementation of Row/Table Data Gateway pattern, which works very well when used right, it’s quite faster than ActiveRecord, basically by making you write complicated queries in SQL, rather than PHP. If you really need a proper ActiveRecord – just drop Doctrine in the library folder and you have it!
ZF is a very smart product, but well have to be patient until it gets more robust (the view is quite limited right now).
Regards
I suspect that the Zend framework is light on the ORM layer because they did not want to duplicate the work of groups like Prople and Doctrine, both of which are strong ORMs in their own right and integrate well into the Zend framework. But I would point out that ORMS themselves are often somewhat limited and heavy handed; in working with Doctrine, I am constantly running into things you just can’t do with it — such as creating non-table fields using functions — and having to wrestle with memory and speed issues you just do not encounter with raw SQL.
I unerstand and appreciate the activeRecord paradigm but I’d warn people looking into it that as with all constructs, ActiveRecord solves a lot of problems well, but it does leave some of the power of free-flowing SQL behind in the process.
I don’t think the lack of an ORM is a disadvantage. I think it has been bad for the community to assume that MVC or Active Record etc solves their problems. I think while MVC as a pattern has merit, Active Record on the other hand can create problems not anticipated by most developers. Active Record is ONE database pattern, not _the_one_true_ pattern.
Why are people so afraid of SQL? I find that most ORMs just get in the way, and tend to be many more lines of code then just writing a simple SQL statement. I guarantee you too that my SQL will be faster then your ORM every time.
So I see why Zend might not include an ORM. Maybe that is a problem they don’t think is worth solving, as pointed out above there are other people who have done it, and some that have done it very successfully.
ADODB is about as far as I go with abstraction. Too much magic makes it hard to figure out what the application is doing.
Bottom line: don’t be afraid of SQL.
@kenrick
Lack of ORM is a disadvantage only when trying to rapidly build something. I’m not a believer in that idea of the_one_true_pattern, just that the right tool sometimes is ORM so you can JFGID (just fucking get it done).
I have to use SQL every day, so I certainly don’t shy away from it. But many times it is faster to use the built-in ORM / ActiveRecord / Associative Data Mapper that frameworks often provide.