I have the exact question that this guy has: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29
I'll just copy-paste it here:
I was wondering what different ways of organizing bundles within a project people are using.
I seem to end up with either one massive bundle for a project or a lot of bundles which are closely related (dependant) to each other. eg;
I implemented my own user entity and login forms etc, but the users are linked to an organization (with some functionality). Etc ... It's mostly the entities that overlap a lot I guess ...
Do you guys split them up or dump them all in the same bundle?
Edit: I don't use bundles for app-specific code anymore.
Personally I prefer to have a bundle per a section of an application. For example:
- UserBundle
- BlogBundle
- ForumBundle
- JobBundle
- StoreBundle
- etc
This is okay if the app is a mishmash of several functionalities, none of which is big enough to require a separate application and/or a subdomain. But if I was developing a big webstore applicaton, my bundles would be more specific:
- UserBundle
- ProductBundle
- CartBundle
- SearchBundle
- WishlistBundle
- etc
So, I'd say, it depends on the focus of the project. What's just a section for one project could be the core functionality of another.
And I usually have CommonBundle, where all the common stuff goes, like global CSS, images, layouts, etc.
Also there are at least two options for the backend organization:
- each bundle has its own backend section, or
- there is one big backend bundle.
Personally I lean towards the first option and you can read about it in my previous answer, but there are people who prefer to have a separate bundle for the whole backend — probably using one of the admin bundles.
By the way, it's perfectly okay for bundles to be interconnected — you don't have to make them all independent of each other. For example, JMSDiExtraBundle depends on the metadata library and JMSAopBundle, which in turn depends on cg-library. If you'll try to keep bundles totally independent, you'll end up with big monolithic one-bundle lumps of code.
For every project I start off with one CoreBundle, where I put everything together. Then I just develop features in it and as time goes I reevaluate it - if I might use this feature somewhere else someday (or even release to open source), I move it to a new bundle.
"Size" of the feature worth separate bundle doesn't really matter - I've seen OS bundles as big as a 1 single js file :D
One thing for sure - stuffing everything in a single bundle is bad, it goes against the whole reason why this architecture was implemented in the first place!
My answer in the following topic can probably help you : Symfony 2 : Location of Entities
I'm not a Symfony2 master, but I think I have quite a good idea of the bundle design ; of course, there is no universal answer but you can follow some "best practices".
First of all, I don't think that big bundles are a good solution ; you doesn't split your project into applications anymore, like you did with Symfony1.4. You may ask "but what can I do with the frontend/backend logic ?" ; quite easy, use the controller !
Each bundle should refer to a module, a stone in your project's wall. You have to divide your application ; many bundles are not bad. Of course, don't do a bundle for each entities, that would be a waste of time. But imagine a blog application : you would have an User bundle, Articles bundle (which would manage posts, categories, ...), eventually a bundle for static pages, ...
It's not unlogical that your bundle are linked ; you are building a whole application, so in this case they are linked. But the keyword here is "generalization" ; your bundle should be able to be linked to others bundle, not only yours. You should be able to re-use it in others projects.
Good luck !
来源：https://stackoverflow.com/questions/8415760/how-do-you-organize-your-bundles-in-symfony2-projects