In the previous articles, we dug in to the basic Symfony2 directory structure. Within the src directory, we already had two bundles: one called DemoBundle within the Acme subdirectory and the other one within AppBundle.

DemoBundle is a showcase of an example bundle that has existed since the beginning of Symfony2. It has been created to demonstrate how Symfony2 organizes things. AppBundle is a relatively new thing, introduced in Symfony 2.6 with a new concept of work.

Until the 2.6 version, it was recommended to contain a bundle within the vendor namespace. With Symfony 2.6 and its new best practices rules, it is now recommended to keep the custom application code within the handy AppBundle and create other bundles only if you want to create reusable code to be shared among your other projects.

Bundles don’t have a fixed directory structure. In fact, you can have a bundle without most of the directories. If you create a utility bundle, it will probably have only some custom directory structure for your own set of libraries and tools and will not contain any of the standard directories.

The standard directories are as follows:

  • Command: The Command directory holds command-line tasks, which are visible when you type:
    • php app/console
    • You can see example tasks, and we will create one further in this book
  • Controller: The Controller directory holds the MVC controller classes. You are not limited to a single controller, you can create as many of them as you want. Controllers are our entry classes, and actions within the controllers are called as defined within routing files.
  • Document: The Document directory is used to hold the Document files used by Object Document Mapper (ODM). Documents are PHP classes that reflect the MongoDB documents. In future, other document engines may use this, but currently, if you find the Document directory in a Symfony2 project there is a great chance that it contains files related to the MongoDB documents.
  • DependencyInjection: The DependencyInjection directory contains a few classes to help in loading bundle services. Usually, if your bundle has its own services (we will discuss this term later in this chapter), you will find some code to load in this directory. It is not required, not every bundle needs services or a special configuration.
  • Form: The Form directory contains classes to handle various HTML forms. Usually, this directory contains a subdirectory with the Types and Subscribers forms and other helper classes to define, validate, and process various form data.
  • Entity: The Entity directory is similar to the Document directory, but it is used to hold entities for SQL databases such as PostgreSQL or MySQL. These files are used by Doctrine Object Relational Mapper.
  • Resources: The Resources directory holds non-PHP files related to the bundle. It can be a service definition, routing definition, validation, database entities definition, views, and custom documentation related to the bundle as well as some public files to be copied, or linked to the main web directory.
  • Tests: The Tests directory contains, as you may figure out — classes for automated testing.


    You are not limited, and not bound, to use these directories. It is handy to keep the preceding structure as a lot of things are easier this way, but if you want, you can create your own structure. As an example, Symfony2 provides some shortcuts in the BundleName:ClassName or ClassName:actionName forms, which will work only if you keep a correct structure. Without this, you will be forced to use the full class name (with namespace). This approach is called convention over configuration—you can follow the convention to simplify things, but you can configure it differently if you need to.

There are other standard directory structures that are less common such as EventListener, Service, and Twig, but there are no rules for this. It’s up to the developer to choose his own path and structure to organize code.