I've been working on a Zend Framework application which currently does a bunch of things through Zend Application and a few resource plugins written for it.

However, looking at this codebase now, it seems to me that using Zend_Application just makes things more complicated; and a plain, more "traditional" bootstrap file would do a better job of being transparent. This is even more the case because the individual components of Zend -- Zend_Controller, Zend_Navigation, etc. -- don't reference Zend_Application at all. Therefore they do things like "Well just call setRoute and be on your way," and the user is left scratching their head as to how to implement that in terms of the application.ini configuration file.

This is not to say that one can't figure out what's going on by doing spelunking through the ZF source code. My problem with that approach is that it's to easy to depend on something that's an implementation detail, rather than a contract, and that all it seems to do is add an extra layer of indirection that one must wade through to understand an application.

I look at pre ZF 1.8 example code, before Zend_Application existed, and everywhere I see plain bootstrap files that setup the MVC framework and get on their way. The code is clear and easy to understand, even if it is a bit repetitive. I like the DRY concept that Application gets you, but particularly when I'm assuming first people looking at the app's code aren't really familiar with Zend at all, I'm considering blowing away any dependence I have on Zend_Application and returning to a traditional bootstrap file.

Now, my concern here is that I don't have much experience doing this, and I don't want to get rid of Zend_Application if it does something particularly important of which I am unaware, or something of that nature. Is there a really good reason I should keep it around?

2 Answers 2


Call me simplistic, but I don't see a reason to essentially rewrite a large portion of your code base that you describe as working well for no reason other than it seems to make things more complicated. Seems like a recipe for disaster, to me.

  • Not really a large portion. Basically just the bits that say "the controllers are located here" -- what application.ini does itself. Though I agree rewriting for the sake of rewriting makes little sense (+1 for that). Nov 18, 2011 at 21:39
  • In my experience with ZF, anything that touches controllers is probably going to end up affecting a lot more than you initially think it will. Your mileage may vary. Nov 18, 2011 at 21:40

For a single, existing project that works fine, there is probably a fair argument about not bothering to migrate to Zend_Application.

On the other hand, one of the nice things about Zend_Application is that you can create standalone application resource plugins that are then usable across projects.

In addition to custom application resource plugins that I write myself for use in projects, I have also found many resources that are packaged/published this way. The best example of this is the Doctrine2 application resource written by Guillherme Blanco.

  • +1 -- but how is this different than just creating a library and calling a function from the bootstrap? (That's reusable and a hell of a lot simpler) Nov 19, 2011 at 19:12
  • Well, that's pretty much what the app resource plugin does; it just conforms to an interface Zend_Application_Resource_Resource. And by subclassing Zend_Application_Resource_ResourceAbstract, you get most of the interface for free (plumbing for handling options and Bootstrap-awareness); you only need to implement the init() method, the analogue of the func you suggest. Probably same effort to write. For a non-ZF-experienced dev, you may have a point. But I find it aesthetically pleasing to have bootstrappable resources reside in their own class implementing an established interface. Nov 20, 2011 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.