The new approach

After several months since I wrote this answer, my approach has changed, so I’m sharing it with the community. This answer is still pretty popular and can lead newcomers to the approach I don’t think is the best one anymore. So…

Now I have only one app specific bundle and I call it AppBundle. There were several problems with the old approach and here are some of them:

• Creating a lot of bundles is tedious. You have to create a bundle class and a bunch of standard folders for each new bundle and then activate it and register its routes and DI and whatnot.

• Unnecessary hardcore decision making process. Sometimes you just can’t decide which bundle a particular thing belongs to because it’s used by more than one bundle. And after you spend a half a day and finally make your hard decision on where to put it, you’ll find that in a couple of days or weeks you won’t be able to tell right away which bundle to look that thing in — because most of the times the decision wasn’t based on pure logic and you had to choose based on a coin toss or whatever means you use to bring higher powers for help.

  I suggested using CommonBundle for common stuff in the past but doing that you’ll have to do a lot of unnecessary refactorings moving a thing to and from CommonBundle based on how many or few bundles will use that thing later.

• App specific bundles are interdependent anyway. When people meet the idea of bundles for the first time, one of the main thought that goes through their minds is something like “Yay! I’ll have me a bunch of reusable bundles!” That idea is great and I have nothing against it; the problem is that app specific bundles are not that reusable anyway — there are interdependent. Forget about reuse in this case.

• No idea where to put Behat features and step definitions. This problem is related to the previous ones: you have to repeat the same brainless motions for each bundle and then make hardcore decisions.

  When I started writing Behat features, I just couldn’t decide where to put a lot of features and step definitions because they belonged to several bundles at a time. Putting them into CommonBundle seemed to be even worse, because that’s the last bundle I would look for that stuff in. So, I ended up creating FeatureBundle for that.

Switching to a single bundle solved all these problems.

I’ve also seen some people having a separate bundle for, say, all the entities. I don’t like this approach neither and actually suggest keeping entities and other non Symfony2 specific stuff out of the bundles.

Note again that this new approach applies to app specific bundles. Official docs and other places are full of great advice on how to structure bundles intended to be shared with others and reused across numerous projects. I write bundles of this type as well. But what I’ve found out after months of working on Symfony2 projects is that there is a difference between the bundles intended for reuse and the app specific ones — one approach doesn’t fit all.

And, of course, when you see something reusable emerging in your app specific bundle, just extract it, put it in a separate repo and install as a vendor.

Also I’ve found myself using subnamespaces much more actively as a way to partition the bundle logically — instead of creating a bunch of bundles for that and going through all those troubles.

The old approach

There are no hard and fast rules or silver bullets, but I’ll share my approach of doing things — maybe it will give you an insight or two.

First of all, I don’t have two all-encompassing bundles like FrontendBundle and BackendBundle. Instead, my bundles have both frontend and backend controllers, views, etc. So, if I strip everything from my UserBundle except for controllers and views, its structure would look like this:

UserBundle
├── Controller
│   ├── Admin
│   │   └── UserController.php
│   └── UserController.php
├── Resources
│   └── views
│       ├── Admin
│       │   └── User
│       │       ├── add.html.twig
│       │       ├── delete.html.twig
│       │       ├── edit.html.twig
│       │       ├── form.html.twig
│       │       └── index.html.twig
│       └── User
│           ├── edit.html.twig
│           ├── sign-in.html.twig
│           ├── sign-up.html.twig
│           └── view.html.twig
└── UserBundle.php

Second, I have CommonBundle which I use for stuff shared by several bundles:

CommonBundle
├── Resources
│   ├── public
│   │   ├── css
│   │   │   ├── admin.css
│   │   │   ├── common.css
│   │   │   └── public.css
│   │   └── img
│   │       ├── add.png
│   │       ├── delete.png
│   │       ├── edit.png
│   │       ├── error.png
│   │       ├── return.png
│   │       ├── success.png
│   │       └── upload.png
│   └── views
│       ├── Admin
│       │   └── layout.html.twig
│       └── layout.html.twig
└── CommonBundle.php

My app/Resources/views/base.html.twig is almost the same as it comes with Symfony Standard distribution:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8" />
        <title>{{ block('title') | striptags | raw }}</title>
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        {% block body %}{% endblock %}
        {% block javascripts %}{% endblock %}
    </body>
</html>

Both CommonBundle/Resources/views/layout.html and CommonBundle/Resources/views/Admin/layout.html extend app/Resources/views/base.html.twig. Other bundles’ templates extend one of these two layouts, depending on whether they are for frontend or backend. Basically, this is how I’m using the Three-level Inheritance approach.

So, I’d put your date displayer into CommonBundle. Depending on its complexity it could be just a template, a macro or a Twig extension.

Pagination is a common problem, so I suggest you to use one of the existing bundles instead of reinventing the wheel — if they suite your needs, of course.

And yes, it’s perfectly okay to have bundles without controllers or views, etc.