Skip to content

[DI] Add section about service locators #7458

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 4, 2017
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
227 changes: 227 additions & 0 deletions service_container/service_locators.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,227 @@
.. index::
single: DependencyInjection; Service Locators

Service Locators
================

What is a Service Locator
-------------------------

Sometimes, a service needs the ability to access other services without being sure
that all of them will actually be used.

In such cases, you may want the instantiation of these services to be lazy, that is
not possible using explicit dependency injection since services are not all meant to
be ``lazy`` (see :doc:`/service_container/lazy_services`).

A real-world example being a CommandBus which maps command handlers by Command
class names and use them to handle their respective command when it is asked for::

// ...
class CommandBus
{
/**
* @var CommandHandler[]
*/
private $handlerMap;

public function __construct(array $handlerMap)
{
$this->handlerMap = $handlerMap;
}

public function handle(Command $command)
{
$commandClass = get_class($command)

if (!isset($this->handlerMap[$commandClass])) {
return;
}

return $this->handlerMap[$commandClass]->handle($command);
}
}

// ...
$commandBus->handle(new FooCommand());

Because only one command is handled at a time, other command handlers are not
used but unnecessarily instantiated.

A solution allowing to keep handlers lazily loaded could be to inject the whole
dependency injection container::

use Symfony\Component\DependencyInjection\ContainerInterface;

class CommandBus
{
private $container;

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

public function handle(Command $command)
{
$commandClass = get_class($command)

if ($this->container->has($commandClass)) {
$handler = $this->container->get($commandClass);

return $handler->handle($command);
}
}
}

But injecting the container has many drawbacks including:

- too broad access to existing services
- services which are actually useful are hidden

Service Locators are intended to solve this problem by giving access to a set of
identified services while instantiating them only when really needed.

Configuration
-------------

For injecting a service locator into your service(s), you first need to register
the service locator itself as a service using the `container.service_locator`
tag:

.. configuration-block::

.. code-block:: yaml

services:

app.command_handler_locator:
class: Symfony\Component\DependencyInjection\ServiceLocator
arguments:
AppBundle\FooCommand: '@app.command_handler.foo'
AppBundle\BarCommand: '@app.command_handler.bar'
tags: ['container.service_locator']

.. code-block:: xml

<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">

<services>

<service id="app.command_handler_locator" class="Symfony\Component\DependencyInjection\ServiceLocator">
<argument key="AppBundle\FooCommand" type="service" id="app.command_handler.foo" />
<argument key="AppBundle\BarCommand" type="service" id="app.command_handler.bar" />
<tag name="container.service_locator" />
</service>

</services>
</container>

.. code-block:: php

use Symfony\Component\DependencyInjection\ServiceLocator;
use Symfony\Component\DependencyInjection\Reference;

//...

$container
->register('app.command_handler_locator', ServiceLocator::class)
->addTag('container.service_locator')
->setArguments(array(
Copy link

@meyerbaptiste meyerbaptiste May 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recently implemented a service locator for API Platform and the syntax described here is currently not the correct one.

According to src/Symfony/Component/DependencyInjection/Compiler/ServiceLocatorTagPass.php#L40-L42, this should be:

->setArguments([
    [
        'AppBundle\FooCommand' => new Reference('app.command_handler.foo'),
        'AppBundle\BarCommand' => new Reference('app.command_handler.bar'),
    ],
])

Same for the YAML/XML config.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, fixed. Thanks!

'AppBundle\FooCommand' => new Reference('app.command_handler.foo'),
'AppBundle\BarCommand' => new Reference('app.command_handler.bar'),
))
;

.. note::

The services defined in the service locator argument must be keyed.
Those keys become their unique identifier inside the locator.


Now you can use it in your services by injecting it as needed:

.. configuration-block::

.. code-block:: yaml

services:

AppBundle\CommandBus:
arguments: ['@app.command_handler_locator']

.. code-block:: xml

<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">

<services>

<service id="AppBundle\CommandBus">
<argument type="service" id="app.command_handler.locator" />
</service>

</services>
</container>

.. code-block:: php

use AppBundle\CommandBus;
use Symfony\Component\DependencyInjection\Reference;

//...

$container
->register(CommandBus::class)
->setArguments(array(new Reference('app.command_handler_locator')))
;

.. tip::

You should create and inject the service locator as an anonymous service if
it is not intended to be used by multiple services

Usage
-----

Back to our CommandBus which now looks like::

// ...
use Psr\Container\ContainerInterface;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you type hint against this interface? Simple closure is enough, isn't it?

$this->psr11->get(get_class($command)) makes me think that Foo\RegisterUser is a service name, but semantically it isn't.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Goal is to show the provided PSR-11 implem first, so it's clear what you can do when receiving such argument, including throwable exceptions. Just below there's an example showing that it can be used as a callable and how it can be used

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not even sure that PSR-11 makes sense for this feature at all. In this context PSR-11 looks like a replacement for the Java's Map: you need some generic explicit interface, with NotFound* exception and get/has methods, but PHP doesn't have it (ArrayAccess is kinda similar, though), so here we go.

Yes, PSR-11 maps string on object, but semantically string here is not serviceId, but something more generic. It looks like far-fetched concept here.

I can't imagine case when I need to type hint against the PSR-11 interface unless I really do something highly cohesive with DI-containers, where I want to say explicitly: "yes, this is about DI-containers", e.g. decorator for DI-containers which logs service ids.

Second example with callable looks for me better even if it has implicit interface. At least, it has nothing to do with DI-containers.

So the example with PSR-11 interface looks a bit unnatural for me. Probably, it's just me. Just my 5 cents.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yet I understand your concerns, I think PSR-11 is legit in this context since the primary goal of the locator is to fetch services from the DIC (keeping in mind that this doc is about symfony/DI).
I find the callable typehint useful for cases where there's no DIC behind the locator, which should not be the main usage of this feature to me since it is first built to avoid container-aware stuff inside the symfony full stack.

semantically string here is not serviceId, but something more generic. It looks like far-fetched concept here.

In my opinion, services identifiers should remain the same in the locator than in the container from which they come from, so they're safely accessible no matter which container/registry/locator/provider is given to you, that is primordial to me.
Redefining identifiers might just be useful in some cases that I'm still not sure to get, but it seemed logic for others so here we are.

Second example with callable looks for me better even if it has implicit interface. At least, it has nothing to do with DI-containers.

As you pointed out in the code PR, container is just a kind of map after all and if you ask me, PSR-11 could be called Object[Store|Provider|Locator|Registry] instead of Container.


class CommandBus
{
/**
* @var ContainerInterface
*/
private $handlerLocator;

// ...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may write the constructor here to understand the correlation between the service declaration and the class instanciation

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, definitely needed for a good understanding.


public function handle(Command $command)
{
$commandClass = get_class($command);

if (!$this->handlerLocator->has($commandClass)) {
return;
}

$handler = $this->handlerLocator->get($commandClass);

return $handler->handle($command);
}
}

The injected service is an instance of :class:`Symfony\\Component\\DependencyInjection\\ServiceLocator`
which implements the PSR-11 ``ContainerInterface``, but it is also a callable::

// ...
$locateHandler = $this->handlerLocator;
$handler = $locateHandler($commandClass);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not only $handler = $this->locateHandler($commandClass);?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you mean $this->handlerLocator($commandClass) :).
Anyway, the intermediate variable is mandatory, calling $this->handlerLocator() would make the engine look for a handlerLocator() method instead of executing the property as a callable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intermediate variable assignment is necessary for php to understand it's a callable property, and not a method.
But as of PHP7, it could be $handler = ($this->handlerLocator)($commandClass)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, good to know. Let's stay simple there though

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(But this is documentation. I think the current code sample is great for this purpose 😄 )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok guys, thanks!


return $handler->handle($command);