PHP has more frameworks then I have fingers and toes, and that diversity gives developers and architects alike a lot of choices when it comes to solving a problem. It can also be a total headache sifting through the options and making sense of what seems like chaos. As of late I've found myself using Symfony 2 to solve my problems and I am increasingly a fan of it's underlying architecture and the freedom it gives developers to work in slices or components of an application.

A fair amount of debate has hit the internet about the dependency model of certain Symfony 2 components. Some argue that component A with dependencies B and C is too much, or that because component A also requires dependencies D, E and F to run it's unit tests it's not a truly stand alone component and instead represent a "coupled" library or framework.  I actually think there is a lot of merit in these assessments, but I don't believe it discounts Symfony 2 from being my MVC framework of choice.  Nor do I think this somehow invalidates the fact that Symfony 2 stands distinctively different from the alternatives in the PHP community. Symfony 2 is a huge step forward from the land of tightly coupled frameworks (I'm looking at you Cake!).  More importantly than the dependency model though, I think Symfony 2 presents an architecture of "Bundles" that simply doesn't get enough love in the current framework debates.

A bundle in Symfony 2 is nothing more then a stand alone unit of code.  It may have dependencies, but it's stand alone in the sense that it represents a functional chunk of an application.  A well designed bundle could theoretically be deployed as distinct unit from an application.  Think about an application where you have an internal messaging system.  Wouldn't it be nice to be able to peel that message system out of the main app and to develop it independently?  When I say independently, I mean completely functioning on a web server without the rest of the application.  This is bundle development at its finest.

Don't get me wrong, lots of bundles are not developed this way.  I've seen applications where bundle divisions are completely arbitrary and others that had a nasty web of cross dependencies such that they should have just been in the same bundle.  There is a happy place however, where bundle development represents a unique sliver of a larger application, and that place is why I'm so drawn to Symfony 2.

I've been working on a reporting bundle for a little while now. It's a simple concept, take an arbitrary query and translate it into a table. When I am developing it locally I actually have it bootstrapped into a vanilla Symfony Standard edition created by composer.  When I am done with changes I deploy them into two different apps I've written that both use this bundle.  The apps themselves have very little knowledge of the bundle, just enough to put some links into their respective menus, import a routing configuration and that's about it. What's most important though is that the reporting bundle itself has no knowledge of the two apps, such that I can develop it independently and deploy it to both without disrupting anything.  The immediate benefits of this are rapid development and deployment, allowing for changes to trickle out to actual software faster.

This sort of development, application by slice or bundle, in a big team can optimize workflow by an order of magnitude.  You can have a team iterating independently at a rapid pace without disrupting the other teams.  In the end you have a forward moving application of independent and highly functional units. What's not to love about that?

Symfony 2's implementation is unique in my opinion because of things like extensions, compiler passes, bundle inheritance and the power of template inheritance. These aspects of Symfony 2 really empower unique slivers of code.  When done right it's completely possible to develop a bundle that doesn't even need Symfony 2.  Want to bootstrap a new framework and use your bundle?  You can do that - it just requires some deliberate planning at the onset (aka inject, inject, inject!).  Now some will read this an appeal to the awesomeness of Symfony’s dependency injection component and argue that’s really where the power of these slivers come into play.  I disagree, I think it’s a piece of the pie - but fundamentally there is an underlying architecture and set of principals that lends itself to lose coupling of pieces of an application.  What I wish though, is that this bundle mentality would materialize in some other frameworks!

** After writing this I was challenged with the notion of “plugins” or “modules” as they appear in some other frameworks.  In my opinion most of the “things” that use this terminology lack the looseness of a Symfony bundle. A well written Symfony 2 bundle can in my opinion be bootstrapped without using Symfony.  It requires writing Controllers that stand alone and are injected and it requires having a full grasp of your dependencies (no $this->createForm() please), but it can be done and the power of that independently deployable bundle is something that plugins and modules simply have not proven they can do just yet.