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.

I suggest creating a DateDisplayerBundle and a PaginatorBundle instead of putting their related code in a more general bundle. There are a few reasons for this:

• The role of each bundle is very clear, and you know where your code is.
• Sharing pieces of functionality (date displayer, paginator) between different projects is simpler when you have separate bundles, versus one general bundle that you then may need to prune.

There's no hard rule saying that bundles must have controllers. Bundles can have any mix of business logic, templates, controllers, and configuration, but there's no restriction on what you can store in them.

On the other hand, if your functionality is not very complex, it may not warrant being contained within a bundle at all. In this case you could create a library in /vendor for it. Symfony makes use of a number of libraries in this fashion (see Monolog and Doctrine for example.)

As for your second question, I think the reason for keeping layouts in app\Resources\views is because it's a convenient way for you to keep track of all your layouts. When you have a project that has many bundles, you might lose track of where a certain layout is. But if you keep them all within one centralized location, you'll always know exactly where to look. As with many things in Symfony2, this isn't a rule that's set in stone. You could easily store your layouts in a bundle, but I don't think it's the recommended practice.

As for your question about your general Root bundle, I would say in most cases you should avoid shoehorning a bunch of different features in one bundle. See my earlier points about keeping your bundles specific. When I started developing with Symfony2, I had some trouble determining what code should go in what bundle. It's not how I was used to thinking about programming. But eventually you start to see how the individual pieces of the puzzle fit, and that makes determining the bundle structure easier.