Symfony Components: Sometimes Decoupled, Sometimes Not

Previously, on decoupling and dependencies, I said: “Some [Symfony] commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states.”

I’m willing to allow that the Symfony commenters here might be right. Let’s try looking at Symfony’s claims and see how they stack up. Regarding the decoupling of their components, the Symfony website states:

Beside being a full-stack framework, Symfony is also a set of decoupled and standalone components.

What is a Component?

Symfony Components implement common features needed to develop websites. They are the foundation of the Symfony full-stack framework, but they can also be used standalone even if you don’t use the framework as they don’t have any mandatory dependencies.

That page then lists the following as their “decoupled” “standalone” components that “don’t have any mandatory depedencies”:

- BrowserKit             ~ EventDispatcher    ~ Routing
+ ClassLoader            + Finder             - Security
+ Config                 - Form               + Serializer
+ Console                + HttpFoundation     + Templating
+ CssSelector            - HttpKernel         ~ Translation
~ DependencyInjection    + Locale             ~ Validator
~ DomCrawler             + Process            + Yaml

After reviewing the master Github branches for the components’ composer.json files, and in some cases the code itself, I conclude that Symfony’s claim of “decoupled” “standalone” components is clearly true for 11 of those packages (marked with a + above) and clearly false for 4 of them (marked with a -). I think the claim is debatable for the remaining 6 components (marked with a ~) and I may take up that debate at some later time.

The 11 components for which Symfony’s claim is clearly true are: ClassLoader, Config, Console, CssSelector, Finder, HttpFoundation, Locale, Process, Serializer, Templating, Yaml. These composer.json for these components has no “require” for another Symfony component, and my brief review of the codebase did not reveal any hidden dependencies.

The 4 components for which Symfony’s claim is clearly false (i.e., composer.json notes at least one “require” for another Symfony component) are:

  • BrowserKit (requires DomCrawler)
  • Form (requires EventDispatcher, Locale, and OptionsReslover [which is not listed in the components])
  • HttpKernel (requires EventDispatcher and HttpFoundation)
  • Security (requires EventDispatcher, HttpFoundation, and HttpKernel)

As such, I think it is clearly false that all Symfony components are standalone and decoupled with no mandatory dependencies. Does having mandatory dependencies make it a bad project? Not at all. It just means their statement of “no mandatory dependencies” (and related statements) is not true for all the components listed.

Now, it may be that the Symfony folk have a different idea of what “decoupled” and “standalone” mean. Are they decoupled from the framework? Sure. But are they decoupled from each other? The answer appears to be “not always.”

In comparison, all Aura packages (aside from the Framework package as previously noted) are fully decoupled from the framework composed of them, and also from each other. There no mandatory dependencies, and there are no suggested/optional/sometimes/maybe dependencies. Does that alone make it a good project? Not at all. It just means my claim about decoupled packages in Aura is completely true.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

29 thoughts on “Symfony Components: Sometimes Decoupled, Sometimes Not

  1. And the one thing I don’t like is if you look into a package, for the easiness they keep everything in a single place. Eg : for integrating the event dispatcher or http or something they keep all the code there itself.

    And its hard for people like me to understand it . , Who knows may be Form will become too tedious for aura also 😀 .

  2. I think the issue boils down to whether you define “decoupling” as “no coupling” or “low coupling”. In my opinion, no coupling can be good, but low coupling will be sufficient too if it is needed to keep your code cohesive.

  3. I really wish the discussion and many posts would be in a different topic or rather explaining things inside Aura and architecture. Really fighting things like you are red and i am yellow spends your and our time on useless stuff.

    You are on your n blog post on this. And is a useless pursuit. We all got the point of Aura, but we don’t know anything else besides that is decoupled.

    Thanks, please comply writing blog posts and not need to compare and fire up holy wars.

  4. Cordoval: hey man, I’m not the one who kept arguing it in comments. Everything I’ve said here (and in the previous non-interview posts) has been in response to critics. If there’d been no critics, there’d’ve been no need for me to respond to them. I’ll stop talking about it as soon as you do. 😉

  5. Thanks for the clarifications. Indeed “decoupling” to me does not mean “no dependencies”, to me it means that when designing code extra care is spend to decouple the responsibilities of code units.

    quoting wikipedia:
    “In software development, the term “decoupling” is used to identify the separation of software blocks that shouldn’t depend on each other. Some building blocks are generic and shouldn’t know details of others. Special design techniques allow software designers to have as few dependencies as possible. This typically reduces the risk of malfunction in one part of a system when the other part changed (software regression). It also facilitates future replacement of individual parts of the system.
    Decoupling lowers or minimizes Coupling.”

    So while you say that our statements are “clearly wrong”, I guess its also clear that we are not alone with our definition of the word decoupling.

  6. Do we have different definitions of “mandatory dependencies” as well? The Symfony page states that none of the components have mandatory dependencies, and yet the four components I mentioned do have “require” lines indicating mandatory dependencies in their composer.json files.

  7. As a followup: If Symfony has always intended the Wikipedia definition of “decoupling” as its meaning, one could argue that the framework as-a-whole is “decoupled.” In turn, that means to me there would be no need to differentiate the components as being “decoupled” apart from the framework as-a-whole.

  8. Another followup: we must have different definitions of the word “standalone” as well. Perhaps the components stand alone in regards to the framework as-a-whole, but I don’t see how those 4 stand alone in regards to the other components.

  9. not sure if someone at sensio is currently editing the text, but the page you linked to (and that is being linked to in other places on is currently not available.

    at any rate the 4 components you mention (form, httpkernel, security and browserkit) do indeed have mandatory dependencies and so yes for these the statement “don’t have any mandatory dependencies” is indeed incorrect and should be correct/clarified (not sure if this is being done as I write this). aside from this the rest of the statement does seem to correct to me using a fairly common place definition of the word decoupled and standalone.

    “don’t have any mandatory dependencies”

    • “the page you linked to (and that is being linked to in other places on is currently not available.” Hilarious!

      Meanwhile, one can see similar text on this page, although the list of components is not as long:

      “The Components implement common features needed to develop websites. They are the foundation of the Symfony full-stack framework, but they can also be used standalone even if you don’t use the framework as they don’t have any mandatory dependencies.”

  10. Why don’t you concentrate on showing why your framework is decent rather than every single post trying to batter another framework.

    You say your posts aren’t supposed to batter the other framework yet you always have your little “Aura is better” statement at the bottom of each post.

    • It’s not “battering” at all. I am responding to critics who accuse me of unfairly characterizing their project; I assert that my characterizations are fair and accurate, and will continue to respond as such.

  11. I think its totally ok that Paul uses his blog to clarify his positions. Personally I would at times wish that he would choose to use wording that sound like there isn’t a possibility for an alternative point of view. But I guess most of us tech folk also do not appreciate wishy-washy statements. So it goes .. lets all just focus on the practical benefits that we all are trying to bring to the discussion. This particular post to me highlights that the “don’t have any mandatory dependencies” statements on should be corrected.

    • Lukas: You said, “This particular post to me highlights that the “don’t have any mandatory dependencies” statements on should be corrected.”

      I think that’s one of the right things to take from this. Thank you. 🙂

  12. “There no mandatory dependencies [in Aura]. Does that alone make it a good project? Not at all.”

    This is the core of it. I don’t think Zend, SF2, and Aura are really significantly different except in size. Aura seems to have a particular focus on its components working completely without dependencies, Zend (by the nature of its distribution) tends to assume the rest of the library is available, and SF2 is closer to Aura than Zend, but still somewhere in between.

    My prediction is that (if you intend to make more and more Aura components) there’ll be times where the design decision to make every component completely standalone will raise issues like unnecessary duplication of code, or expanding the scope of individual components to do more things (instead of keeping them simple and instead creating a new component that would share some of the code). This is where I think that Symfony has been (generally speaking – it’s not perfect) pragmatic at the expense of fully decoupled. It’d be interesting to me to know how you intend to deal with this conflict when it occurs in Aura development – is the principle important enough to you that you’d avoid making a component that ought to use dependencies?

    For example, the Form component is Symfony’s red-headed stepchild. It has more dependencies than the framework component itself (http-kernel: 2 deps, form: 4 deps). It’s probably the thing I see the most chatter about on the Symfony mailing lists. But in its defence, I think it’s very difficult to make something with the same capabilities that it has without stepping on things like input-handling code (like Aura Filter), model handling code (like Aura Marshal), and template-handling code (like Aura View) unless you either decouple things so far that your users end up writing lots of code to use it (like validating form input and your model separately, writing your form HTML by hand, etc), or you end up duplicating the functionality of other components, breaking DRY, KISS, and SoC.

    How would you go about making an Aura form component? Have you avoided it consciously because it’s incompatible with your design goal of decoupling, do you intend to make one later and are still thinking about how? Or do you disagree with the need for something like the Form component at all, and see it as many separate tasks and not one single one?

  13. I havent read other comments, but can concur with the title.

    ive spent the last 3 weeks or so, attempting to get a base application running on top of symfony’s components. for clarity, the packages i wanted to use:

    http foundation
    dependency injection
    event dispatcher
    http kernel

    my own personal experience of using Symfony is mixed. part of is very easy to use, easy to grasp and documented well – however, the documentation only seems to cover the basic implementations and its always assumed you are using the ‘FrameworkBundle’. in my case, im not using this bundle, and some pain has been felt along the way of trying to wire things up how i want them to be.

    two of the biggest gripes ive so far are the container implementation and using your own controllers (ie, not extending the FrameworkBundle::Controller class) and templating with forms. templating on its own was great and easy; but it appears using forms means you MUST use either Twig, or the FrameworkBundle. this is definitely NOT a standalone component. i did see a pull request here: which would provide what i need, but it has not been implemented to date and im not sure of the status of it.

    the only way ive gotten around this templating issue is to extend the Form/Extension/Templating/Renderer classes, but i shouldnt need to do that. the FormHelper should be shipped with the standalone component, so as any templating engine can utilise it. otherwise, the form component on its own is pretty useless unless you plan to not render it (eg, nobody).

    a final note, is that its also true that symfony also does bring in other components not listed within your composer – for example, optionsresolver, etc etc. personally im not fussed about that as long as the component actually works itself – which in the case with templating and forms above, sadly doesnt.

Leave a Reply

Your email address will not be published. Required fields are marked *