As some of you might know, the Symfony2 framework consists of two main ingredients:
The logical separation should be the following:
The Symfony Components are standalone and reusable PHP classes. With no pre-requisite, except for PHP, you can install them today, and start using them right away. (Symfony Components Web Site)
A Bundle is a structured set of files (PHP files, stylesheets, JavaScripts, images, …) that implements a single feature (a blog, a forum, …) and which can be easily shared with other developers. (Symfony2 Documentation)
Of course, there are different vendor libraries that Symfony2 uses, that are not Components or Bundles. Its important to remember, that in order to expose that functionality in your Symfony2 application and make it accessible, you have to create a Bundle. Its a good practice and an unwritten convention.
I think that the main reason for doing so is to avoid setting up third party libraries yourself and delegate that to Symfony2’s DIC component, which was built for that very purpose. This lets other developers overload some of your configuration, class names and parameters without modifying your core classes and breaking backwards compatibility.
DIC stands for Dependency Injection Container.
The main idea behind Dependency Injection Containers is to extract all the instantiation and wiring logic from your application into a well-tested dedicated component, avoiding the code duplication that inevitably happens if you’re practicing Dependency Injection and Testability without DIC. By removing all of the setup code, Symfony2 removes another possibility of error and lets you concentrate on your domain problems instead of object instantiation.
Each object in Symfony2 DIC is called a Service. Service is an instance of some Class, that is created either by direct instantiation using the ‘new’ construct or using some other Service’s factory method, that gets certain dependencies injected into it as part of the instantiation process.
It is much easier to understand how services are configured by looking at an example configuration:
I personally find it very readable.
During the container instantiation, the XmlFileLoader takes the above-mentioned services.xml file and transforms it into PHP code, which looks similar to the following pseudo-code:
Now you have sort of a bird-eye view of how your objects are built and interact all in one place. No need to open some bootstrap file to see how everything gets wired together, and most importantly, no need to touch your code in order to change how things get wired together. Ideally, we want application to be able to perform completely different tasks, just by re-arranging some dependencies.
NOTE: All of your DI xml (or yaml or php) configurations need to live under <bundle name>/Resources/config directory of your application, in our example, I would store the configuration in MyCompany/PaymentBundle/Resources/config/services.xml.
The next step is to let your Symfony2 application know that you have this service configuration and want it to be included in the main application container. The way you do it is very conventional, although I know at least one way to make it configurable, but that’s a different topic and deserves its own blog post.
In order to include your custom configuration, you usually need to create something called Dependency Injection Extension. A DI Extension is a class, that lives under <bundle name>/DependencyInjection directory, that implements Symfony\Component\DependencyInjection\Extension\ExtensionInterface and which name is suffixed with ‘Extension’.
Inside that class, you need to implement four methods:
- public function load($tag, array $config, ContainerBuilder $configuration);
- public function getNamespace();
- public function getXsdValidationBasePath();
- public function getAlias();
Or you could choose to extend Symfony\Component\DependencyInjection\Extension\Extension and have to worry only about the last three.
Let’s look at an example extension, that would register our services.xml configuration file with Symfony2’s DIC:
This extension does several things:
- It will include the services.xml into DIC only if ‘payment_gateway’ service is not yet defined - this is to avoid conflicts and lazy-load the configuration
- It will override some of default parameters, if you specify your own when enabling the extension
- It also provides the XSD schema location and base path for validation of XML configuration
After you created the extension, all you need to do is add PaymentBundle to the application Kernel::registerBundles() method’s returned array. Then in the application configuration file specif something like ‘payment.config: ~’ (assuming you’re using yaml configs). That should do it, you should now be able to call $container->getService(‘payment_gateway’) and get the fully set up instance of Gateway.
Happy Coding!
