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
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:
Commanddirectory holds command-line tasks, which are visible when you type:
- You can see example tasks, and we will create one further in this book
Controllerdirectory 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.
Documentdirectory is used to hold the
Documentfiles 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
Documentdirectory in a Symfony2 project there is a great chance that it contains files related to the MongoDB documents.
DependencyInjectiondirectory 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.
Formdirectory contains classes to handle various HTML forms. Usually, this directory contains a subdirectory with the
Subscribersforms and other helper classes to define, validate, and process various form data.
Entitydirectory is similar to the
Documentdirectory, but it is used to hold entities for SQL databases such as PostgreSQL or MySQL. These files are used by Doctrine Object Relational Mapper.
Resourcesdirectory 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.
Testsdirectory 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
ClassName:actionNameforms, 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
Twig, but there are no rules for this. It’s up to the developer to choose his own path and structure to organize code.