July 5th, 2008
Posted by Fred Wu
Two weeks ago I started working with Zend Framework at work. I chose to use Zend Framework for one primary reason: Zend. Even though I have plenty of experience with CodeIgniter and Kohana, I simply could not take any risks using them for a rather large project at a company I had just joined.
My experience so far is mixed. Probably because I am so used to the way CodeIgniter and Kohana do things, Zend Framework just appears utterly complicated and difficult to work with (at the beginning).
I am curious about all the people wanting ActiveRecord for ZF, well, from my experience, it is not possible to create an AR like orm for php 5.2.6. mainly because of static function problems, if you get pass that (of course it would look darn ugly for current php release) then you will need to, for example, send arrays to your finder function to have smth like named args(which after all is not such a big problem), and then people can go to relation mappings, onetoone(hasone,belongsto) is basic to implement, so is onetomany(or manytoone)-either greedy or lazy, but when you go to manytomany(hasmany, hasmanythrough, hasandbelongstomany), hell happens and not because it gets too complicated to hydrate objects, because the language really stays in your way.
My recommendation in your quest for orm for ZF, checkout doctrine, its shaping quite well as one of the devs likes to say :) and then there is another post on the web about a guy creating automatic zend forms from doctrine models which gives you a prehistoric admin generator :)
I think the “comes from a small vendor” argument isn’t valid for open source, at least not for smaller systems. You might not want to make major changes to somebody else’s framework, but you can certainly fix bugs and add small features.
To me, the Zend Framework isn’t a real framework, but is more of a collection of libraries. It doesn’t come with a cohesive strategy for writing applications as much as symfony or rails does. Like the “.net” framework, it’s trying to bamboozle managers into thinking it’s something it isn’t.
The qualities of the libraries vary from adequate to worse. I was tasked with adapting one of the “web services” implementations to another environment and found that the code quality of the area I was looking at was pretty bad.
Rolling your own in-house framework is less of a bad idea than you might think. Remember that you can get 80% of the functionality for 20% the work, and having every part of your stack optimized for your environment can give you large gains in EVERY department.
————-
As for ORM in PHP, my suggestion is to build something that works by introspecting the database, that uses external configuration files for annotations at most.
It probably makes sense to reduce the scope of the ORM problem to produce a product that actually works: that doesn’t promise more than it can deliver. Completely avoiding the formulation of joins wouldn’t be crazy — ORM’s have always been stronger in the “CUD” department than in the R. Complex queries might benefit from an entirely different approach.
This has happened in the .net world. LINQ applied some brilliant ideas (the language integrated query stuff) to database mappings, but they kept it simple, and didn’t consider anything other than a 1:1 structural mapping between thte database and objects. It’s a great product and people love it.
The entities framework, however, has had people picketing their headquarters in Redmond because they just can’t figure how to make a product that solves the more general problem that doesn’t make more problems than it solves…
And that’s what it comes down to. Somebody has to come out with an ORM that has the motto “Do No Harm”. Even if it means the ORM “does less”.
I always thought that Zend framework gives you the lower part component, standards and naming conventions (witch looks a lot like JAVA’s) And, if one wants to use it he must build his own framework on top of Zend. Where he could handle things like directory structure, test, and so. Zend framework just give you the lower level components.
You might want to check out Sphinx for your fulltext search needs.
It is an external MySQL indexer but integrates very well with PHP and has very good performance.
As for the Zend Framework, it is definitely a larger beast to set up, and it requires more “up front” work than CakePHP or CodeIgniter and the like, but if you are working on a project that has a long-term lifecycle (i.e. not something you “fire and forget” to a client’s webserver), then the structure of something like ZF will save you time and effort in the long run.
It is similar to comparing something like jQuery to the YUI framework. jQuery can get you up and running in no time and certainly looks very sweet and compact in its code, while the YUI framework is more deliberate and requires more time and more lines of code to accomplish things.
But developers should be weary of frameworks and libraries that do what I call “magic”. The day you need to do something that strays from the intended operation of that magical easy-to-use framework (and god forbid that day is 6 months after the last time you looked at your code), you are going to move at a snail’s pace in getting it done and might even have to put in some ugly hacks.
A well-defined, flexible (i.e. no “rails way”), consistent and verbose codebase is a complex long-term multi-developer project’s best friend.
Well, I have to take responsibility for both the 1.5 naming and the poor state of the QuickStart. Lots of people have criticized the version number, but they always give different examples of what we’re missing to justify a version number of ’1.5′. I honestly don’t know why it matters; we called it 1.5 because it was larger in scope than what we were initially planning for our minor releases. The next release will be called 1.6 because the scope is about right AFAIC. Obviously the QuickStart needs some attention. I actually plan to work on it right after I’m done with this comment, but there’s really no excuse for how long its been in the state that it has. I’m sorry, and I hope you will at least find it helpful once I’ve actually completed it. :)
Could you please enter issues for Zend_Search_Lucene in our issue tracker? I’ve just created a ‘performance improvement’ issue type. Alex is working on Lucene 2.3 index file format support this week; if you enter an issue and mail the id to me, I will discuss profiling the entire component with Alex so we can identify any new bottlenecks.
We actually do have an ORM implementation; technically the db and row data gateway patterns are ORM designs. If you’re looking for a more traditional and/or powerful ORM implementation, definitely look at Doctrine or Propel. You should find it easy to use either project with ZF. As far as an AR implementation goes, I don’t think we’ll seriously look at it until we feel that we can bring new value to the PHP community. In general, we try to tackle the areas in PHP that we feel have not been addressed or addressed in a way that we can recommend without reserve to our users. Basically we feel that there’s plenty of stuff to work on without reinventing the wheel. :) That said, Zend_Db_Table is not necessarily our last take on ORM; in particular, we have been looking at what’s been done in LINQ to see what we might be able to add to the PHP community’s box of tricks.
Could you please add issues for the documentation, as well? Documentation is both hard to write (the implementers often have a hard time see the subject matter from the new user’s perspective) and hard to keep in sync. We could always use more help in this area. ;)
Finally, I’ve tried to get everyone at Zend to stop using the phrase “extreme simplicity”. Not because ZF isn’t simple, but because it doesn’t provide the kind of ‘simplicity’ that people have come to expect by using Rails and clones. I put that in quotes, because simplicity just isn’t that simple to define. :) I think you’ll find it’s simpler to use ZF with other projects. It’s definitely simpler to use 1 or 2 ZF components without using the whole thing. It’s probably even simpler when you have custom directory structure requirements that buck all conventions. But it is certainly not simpler to set up an initial project with no custom structure requirements and basic things like controllers/models/etc. by convention with ZF components in the main distribution, and this is what most people think of when they hear ‘simplicity’ WRT web framework in my experience. That said, as one commenter noted, ZF is really a framework to build frameworks on top of. In fact, that’s exactly what the ZF team feels it’s doing with each release. We’re building towards that ‘simplicity’ with components such as Zend_Tool, but because we have built layer upon layer towards the most common of use cases instead of down from them we’ll be taking a bit longer to get there.
@ion gion: Thanks for the comments re AR for PHP. Syntax-wise I don’t really mind, even though Ruby’s syntax does look cleaner. And thanks for the Doctrine suggestion, I’ve tried Doctrine a while ago, it was good (although not as good as Rail’s implementation) but I need to wait for a while before adapting it in commercial projects. :)
@Paul Houle: I agree with you, that Zend Framework is a collection of libraries / components, which I consider is a good move. Developers are able to plug-n-play those components into existing frameworks / application. However, I still think a base MVC bootstrap should be included for convenience sake. :) As for the idea of using an in-house framework, yes that is what I have planned for (see: http://thislab.com/2008/03/17/.....ications/).
A lot of ORM implementations are making things more complicated than they should be. Here is a very good presentation on what is wrong with those ORM solutions: http://dave.org.uk/talks/lpm/2006/orm/ I fully agree with the author and reckon ORMs should be intelligent enough to detect relationships and other information from the database/table/field meta data. It seems crazy to me that if I were to model my database in UML, I then have to reapply the same stuff in my code again. This is against the DIY principle and is difficult for future upgrade / maintenance. I’m not entirely too happy with the AR in Rails either, but at least it has a migration mechanism to keep track of changes.
@RStankov: Agreed. :-)
@Seb: Thanks for the link to Sphinx, I will definitely check it out! I do agree with you to a certain degree regarding the flexibility factor of a framework in multi-developer projects. But it’s not necessarily a bad thing to enforce conventions. Python for instance is looking to encourage one way of doing things in the upcoming 3.0 release.
@Wil Sinclair: Thanks again for your comments! Zend Framework is blessed with people like you who really try to get feedback from the community. I would definitely start to submitting tickets (or even patches if I have time). :)
Regarding the version number. Even though it is only a number I still believe people judge the ‘completeness’ of software by their version numbers. And from what I see, Zend Framework has not reached the golden 1.0 yet. But that’s just a trivia thing anyway. :)
Back to research on ZF now… :)
ZF was a huge let down.
If I wanted to program in Java, I would. ZF brought me back to the days of the bloated behemoth that Java Frameworks were (or small-medium web based apps).
I looked at it for about 5 minutes, laughed, then forgot about it.
I have been using ZF extensively since version 0.2.0 and it’s my framework of choice still. However, I feel that since the first official release of version 1.0 a lot of bloat was added and framework development took a turn for the worse. Components like viewRenderer and the Layout view helper were just introducing more levels of complexity and sometime annoyances instead of building on the strong foundation that the framework had.
I still feel that the framework gives me a lot of production ready components that saved me a great deal of time over the years and helped me form a much more structured application design. The DB abstraction classes are top-notch, the MVC components are overall very good (aside from what I mentioned), Zend_Mail is also useful and the list goes on.
I think the ZF was an important addition to the framework selection for PHP, as an intermediary between Cake and code-igniter. Hopefully version 2.0 will scratch plenty of what’s wrong with the current version and expand on what works well.
The last thing ZF needs is a full blown Rails style ORM implementation. Theres enough nievity and downright miss-information out there currently about MVC model implementations without encouraging further confusion within another popular framework. The vast majority of ORM solutions create unwanted dependancies and promote poor practices, they do no favours for PHPs OO progress.
Equally, since when was a paginator an essential part of a framework? A minor gimick type feature at best – however useful.
Frameworks should promote and assist with best practice implementations by providing flexible constructs to work within. ZF largely achieves this with its loosly coupled approach.
@Bill, I think if you spend more time you’d find that ZF certainly do have its advantages, whether or not they’ll justify the use is another story. :)
@Eran: Thanks for sharing your comments with us! I agree with most of your experience except for the mention of the DB abstraction class. Although that could be my own problem. :)
@Steve: Thanks for sharing your opinion too, I appreciate it. And it’s good to see comments from different perspective. Although, how you believe a paginator is a gimmick is beyond me. ;)
Couldn’t agree more.
Again, couldn’t agree more.
Zend framework is still my framework of choice, though, i’ve never used or tested any other framework. It looks the part, but if documentation continues to be bad it will reflect of the framework itself.
Interesting post Fred, you’ve identified many of the same issues I did – I was going to use ZF for a personal project but just grew frustrated.
Many of these issues will eventually be resolved, but the biggest and perhaps most frustrating is the namespacing – I don’t see how this can be fixed/changed without breaking functionality for a lot of people who already use it.
Cudos to Will for follow all these posts, I think it demostrates his commitment to the ZF.
I’m working with ZF Lucene componenet for couple months and believe me that mostly speed issues are because of wrong indexing or wrong queries. It is like a SQL – if you write inapprioprate query you can get results in minutes…
Nex thing is ZF it is a framework to use in your project, not a ready to go product which can produce blog in 10 minutes. It is more component library.