Guide to using Dependency Injection in symfony2

This article provides an example of creating a simple blog site using the Dependency Injection pattern. A dependency-injection approach is applied to all possible symfony components: controllers, doctrine repositories, forms.



To simplify the article, we reduce the number of pages to two:

• Adding a new post (/ add)
• Displays a list of all posts (/ list)

The final architecture of the application will look like this:

Step 1. Creating an arbitrary service

DI as part of symfony has already been considered on the habre, and also described in detail in the documentation . Therefore, we will immediately begin to create our own services and dependencies. This can be done in three ways: specifying dependencies in the bundle code, through configuration files (YAML, XML, PHP) and using annotations (using the JMSDiExtraBundle bundle that comes standard with Symfony). Each method has its pros and cons. We will use annotations for clarity and reduce the amount of code. Let's start with a class that implements business logic. Let it be a PostManager that handles the addition of a new post:



@DI \ Service - turns the class into a service. The annotation parameters specify the name of the service (app.manager.post) and its attributes.

public = false - this attribute indicates that the created service cannot be called directly from DIC ($ container-> get ('app.manager.post') will result in an error). The created service will be able to use only services that depend on it explicitly (hereinafter, in the example with the controller, it will become clearer).

@DI \ Inject - an indication of the services on which the created service depends. This annotation can only be used with public variables. For private / protected dependency variables, you can use @DI \ InjectParams for the constructor or other ways to create services.



So, we have created the app.manager.post service, which depends on doctrine.orm.entity_manager :



A graphical display of services and links is available in a convenient web interface with the installation of the JMSDebuggingBundle .

')

Step 2. Creating a controller

By default, symfony controllers are not services, but there is a note in the documentation that allows them to be made. Create a PostController using the previously created PostManager:



scope = "request" - this attribute is described in detail in the documentation.

@ Route (service = "app.controller.post") - informs the routing system that this controller is used as a service. In this case, the string values ​​of the redirection rules will change from 'AppBundle: Post: add' to 'app.controller.post:addAction'.

Using the @DI \ Inject dependency ("service_container") requires the parent controller class Symfony \ Bundle \ FrameworkBundle \ Controller \ Controller. As a controller, any classes are allowed, not necessarily derived from a standard controller - in this case, the dependence on DIC can be excluded.



Thus, we have created the app.controller.post service, dependent on service_container and app.manager.post :



Service access to service_container means that it has access to all public services of the project at once (through $ this-> container-> get ('...')). This makes it easier to use the framework, but it’s almost impossible to track communications between services with this approach. Therefore, for application services, it is recommended to use the public attribute = false and follow the rule:

Step 3. Creating a form

This step is not mandatory and rather serves to demonstrate the possibilities and consolidate the material. But in large projects that use a large number of forms, it can be useful to control connections.

In the created controller, we used the PostType form, we will try to define it as a service:



Let's use the created service in the controller:



Now we can trace the connection between the form and the controller:

Step 4. Creating a repository

First way: factory creation

Using Doctrine repositories as services is complicated by the fact that they are not part of Symfony, but are part of Doctrine. But such an opportunity is still there, through the factory creation of services. Unfortunately, at the moment it is not supported through annotations, so you will have to use configs.

In the Doctrine-entity file, specify the path to the repository:



Create a PostRepository to get the page list of posts:



We define the created class as the app.repository.post service:



Add a repository and a list page to the controller:

The second way: the creation of repositories-wrappers

This method uses the Adapter pattern. The standard Doctrine repository is included in our own service repository. Unlike the first method, here everything is realizable by annotations.

In the Doctrine-entity file, we remove the repository directive:



We will need a parent class Repository, dependent on doctrine.orm.entity_manager and implementing the necessary functions of the repository. To do this, we use the inheritance of services :



The service definition will now be in the wrapper repository class itself:



Note: when using annotations, specifying the parameter parent = "app.repository" is not required. JMSDiExtraBundle substitutes it automatically, based on the parent class.



Both methods implement the same functionality and are interchangeable. Therefore, the controller code will not change:



As a result, the dependency graph of the application will take the following form:



To control relationships with this approach, you must follow the rule:

Step 5. Optimization

As you have already noticed, all dependencies of the service are its variables and are created along with the creation of this service. In turn, when creating dependencies, their dependencies are created, thus all the elements of the subtree of dependencies, including unused ones, are created. By the example of app.controller.post, we see that the addAction function uses app.manager.post and app.form.post, and the listAction function is app.repository.post. But all the variables are created when creating the controller, therefore, no matter what function we call, some of the variables will be unused: in the case of addAction, this is app.repository.post, in the case of listAction, app.manager.post and app.form.post. This class consists of two independent parts, in which case they say that it has a low connectivity . The more methods a method works with a large number of variables, the higher the connectivity of this method with its class. The class in which each variable is used by each method has maximum connectivity. Creating classes with maximum connectivity is not always possible, but in our case this is easily achieved by dividing app.controller.post into two independent classes:

Conclusion

The introduction of dependencies in all classes of the system improves the quality of the architecture, but increases its complexity and development time. Therefore, this approach is justified only in large projects. When creating small projects like the site created in an article, you should give it up, however, as well as from using Symfony (in favor of lightweight frameworks).



The working source can be downloaded / viewed here:

github.com/cerritus/demoblog