Skip to content

Instantly share code, notes, and snippets.

@jmikola
Created January 5, 2011 16:53
Show Gist options
  • Select an option

  • Save jmikola/766581 to your computer and use it in GitHub Desktop.

Select an option

Save jmikola/766581 to your computer and use it in GitHub Desktop.
Structuring a main, application bundle for Symfony2

Suggested convention for MainBundle organization

Due to cross-dependencies in our domain model, we've grown accustomed to having all of our application's models in a single bundle. If we continue to do this, there's no logical reason to continue creating feature-specific bundles that hold their own services and controllers.

I propose the following directory structure, for an "Account" feature that will be integrated into MainBundle:

src/Application/MainBundle/
 |- Account/
 |   |- Exception/
 |   |   \- IdentityNotFoundException.php
 |   \- IdentityManager.php
 |- Command/
 |   \- Account/
 |       |- CreateAccountCommand.php
 |       \- DeleteAccountCommand.php
 |- Controller/
 |   \- AccountController.php
 |- DependencyInjection/
 |   \- AccountExtension.php
 |- Form
 |   \- Account
 |       |- ChangePasswordForm.php
 |       \- IdentityForm.php
 |- Resources/
 |   |- config/
 |       |- routing/
 |       |   \- account.yml
 |       \- account.xml 
 |   \- views/
 |       \- Account/
 |           |- created.twig 
 |           \- edit.twig
 |- MainBundle.php

The general rule of thumb is that if your feature would take up a single file named after the feature, it's OK to put it in the parent folder (e.g. AccountController.php), but in most cases you'll nest it in a sub-folder, or prefix with something like "account_" (more appropriate for DIC/routing configs).

If your feature will have special classes (services, managers, exceptions, etc.), those can be organized under a top-level folder in the bundle. This is a departure from the convention of top-level Command, Controller, Form directories, but I believe those are standard enough to deserve first-class treatment.

I also propose that we keep only DIC configurations in Resources/config/ and move routing to a sub-folder for easy organization. XML is generally used for DIC configs, as YAML is used for routing, which makes both fairly easy to distinguish, but this prevents any confusion for edge cases and also avoids a cluttered bucket folder.

@kriswallsmith
Copy link
Copy Markdown

I'd rather not add a DIC extension for each feature. If additional config is necessary, it should flow under main.config, similar to how app.config works:

main.config:
    account:
        foo: bar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment