Recently I realized that some of the problems I encountered in the past could have been easily solved by what I'm about to explain in this post.
The problem: an event listener introduces a circular reference
The problem is: having a complicated graph of service definitions and their dependencies, which causes a ServiceCircularReferenceException, saying 'Circular reference detected for service "...", path: "... -> ... -> ...".' Somewhere in the path of services that form the circle you then find the event_dispatcher service. For example: event_dispatcher -> your_event_listener -> some_service -> event_dispatcher.
Your event listener is of course a dependency of the event_dispatcher service, but one of the dependencies of your event listener needs the event_dispatcher itself! So you accidentally introduced a cycle in the dependency graph and now you need to dissolve it.
The wrong solution: injecting the service container
Assuming there is no way to redesign these services in a better way, you finally decide to make the event listener "container-aware". You will fetch some_service directly from the service container, which gets injected as a constructor argument:
use Symfony\Component\DependencyInjection\ContainerInterface;
class YourEventListener
{
private $container;
public function __construct(ContainerInterface $container)
{
$this->container = $container;
}
public function onSomeEvent()
{
$someService = $this->container->get('some_service');
...
}
}
This will break the cycle since you depend on something else entirely: event_dispatcher -> your_event_listener -> service_container. However, it also introduces a nasty dependency on the service container, making your class coupled to the framework, the service definitions themselves, and making it less explicit about its actual dependencies. Besides, I really think that a dependency issue at configuration level should not affect a class this much.
The solution
There is an entirely different and much better way to break the cycle, which is to avoid any dependency on the main event_dispatcher in your own services at all. Let me explain this to you.
In the past, whenever I introduced a new event in my code, I used the application's main event_dispatcher service to dispatch the event and I also registered any listeners for the new event to the same event_dispatcher, using the kernel.event_listener service tag like this:
services:
my_service:
arguments:
- @event_dispatcher
my_event_listener:
class: ...
tags:
- { name: kernel.event_listener, event: my_event, method: onMyEvent }
However, the application's main event dispatcher depends on so many services (via the event listeners registered to it), that sooner or later the dependency mess will start to show cycles. Still, to work with events, we need an event dispatcher (or event emitter, event manager, etc.). Since our code is already written with the Symfony EventDispatcherInterface in mind, we just need to work around the main event_dispatcher service.
Event subsystems
We can avoid the event_dispatcher altogether by introducing event subsystems.
In the old situation we depended on the event_dispatcher. In the new situation, each set of custom events comes with its own event subsystem. This subsystem consists of a dedicated event dispatcher, and an easy way to register event listeners for the custom events.
Since Symfony 2.3 it's really easy to set up your own event dispatcher and to conveniently register event listeners and subscribers in the same way as before.
Example: a subsystem for domain events
A highly relevant example would be an event subsystem for domain events. You don't want those events to be dispatched by the same event dispatcher that Symfony2 uses for its core events.
To be able to use the domain event subsystem, we first need to define a new event dispatcher service:
services:
domain_event_dispatcher:
class: Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher
Now we want to register event listeners for the domain event subsystem in the following, familiar way:
services:
some_domain_event_listener
class: ...
tags:
- {
name: domain_event_listener,
event: my_domain_event,
method: onMyDomainEvent
}
Truncated by Planet PHP, read more at the original (another 2185 bytes)
more
{ 0 comments... » Symfony2: Event subsystems read them below or add one }
Post a Comment