An Example: Client Scope¶

Other than the request service (which has a simple solution, see the above note), no services in the default Symfony2 container belong to any scope other than container and prototype. But for the purposes of this entry, imagine there is another scope client and a service client_configuration that belongs to it. This is not a common situation, but the idea is that you may enter and exit multiple client scopes during a request, and each has its own client_configuration service.

Scopes add a constraint on the dependencies of a service: a service cannot depend on services from a narrower scope. For example, if you create a generic my_foo service, but try to inject the client_configuration service, you will receive a Symfony\Component\DependencyInjection\Exception\ScopeWideningInjectionException when compiling the container. Read the sidebar below for more details.

A) Using a Synchronized Service¶

Both injecting the container and setting your service to a narrower scope have drawbacks. Assume first that the client_configuration service has been marked as synchronized:

Now, if you inject this service using setter injection, there are no drawbacks and everything works without any special code in your service or in your definition:

// src/AppBundle/Mail/Mailer.php
namespace AppBundle\Mail;

use AppBundle\Client\ClientConfiguration;

class Mailer
{
    protected $clientConfiguration;

    public function setClientConfiguration(ClientConfiguration $clientConfiguration = null)
    {
        $this->clientConfiguration = $clientConfiguration;
    }

    public function sendEmail()
    {
        if (null === $this->clientConfiguration) {
            // throw an error?
        }

        // ... do something using the client configuration here
    }
}

Whenever the client scope is active, the service container will automatically call the setClientConfiguration() method when the client_configuration service is set in the container.

You might have noticed that the setClientConfiguration() method accepts null as a valid value for the client_configuration argument. That’s because when leaving the client scope, the client_configuration instance can be null. Of course, you should take care of this possibility in your code. This should also be taken into account when declaring your service:

B) Changing the Scope of your Service¶

Changing the scope of a service should be done in its definition. This example assumes that the Mailer class has a __construct function whose first argument is the ClientConfiguration object:

C) Passing the Container as a Dependency of your Service¶

Setting the scope to a narrower one is not always possible (for instance, a twig extension must be in the container scope as the Twig environment needs it as a dependency). In these cases, you can pass the entire container into your service:

// src/AppBundle/Mail/Mailer.php
namespace AppBundle\Mail;

use Symfony\Component\DependencyInjection\ContainerInterface;

class Mailer
{
    protected $container;

    public function __construct(ContainerInterface $container)
    {
        $this->container = $container;
    }

    public function sendEmail()
    {
        $request = $this->container->get('client_configuration');
        // ... do something using the client configuration here
    }
}

The service config for this class would look something like this: