You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to make my service layer more clear and pretty looking. To do this, I want to make my code more indifferent to its neighbors.
Something like this:
<?phpdeclare(strict_types=1);
namespaceHomeSweetHome;
usePsr\EventDispatcher\EventDispatcherInterface;
/** * @serviceSays I don't care who uses me. */class Service
{
publicfunction__construct(
privatereadonlyEventDispatcherInterface$eventDispatcher,
# some "we don't care" dependencies# ...
) {
}
/** * @methodSays I don't care who calls me. */publicfunctionmethod(mixed ...$params): mixed
{
/** * @methodSays * I don't care: * - who will listen it; * - how it will be delivered. */$this->eventDispatcher->dispatch(newEvent('some data'));
return'some a result';
}
}
/** * @listenerSays * I don't care: * - who sends me events; * - how they are delivered. */class Listener0
{
publicfunction__invoke(Event$event): void
{
# Some **light work** that needs to be done immediately.# Obviously, this should happen **synchronously**.
}
}
/** * @listenerSays * I don't care: * - who sends me events; * - how they are delivered. */class Listener1
{
publicfunction__invoke(Event$event): void
{
# Some **heavy work**, that can be done later.# Obviously, this should happen **Asynchronously**.
}
}
/** * @eventSays I don't care at all. */class Event
{
publicfunction__construct(publicreadonlystring$param)
{
}
}
Synchronous events/messages can be handled by both of them. I know that the Messenger component has more advanced logic, like middleware - which can be turned off and leave only a sender/receiver logic, but in general, it can do the same job, as the event-dispatcher.
After I installed the Messenger component, I was a bit confused, now I don’t need event-dispatcher, because I have a similar tool.
From my perspective, it’s better to use “service layer” interfaces or PSR interfaces in dependencies instead of some framework stuff. Symfony makes it possible to use the PSR interface for event-dispatcher and that's pretty cool, but I can't:
use it for async events;
overwrite the PSR event dispatcher interface with the Messenger bus class, since many parts of the framework use it (and dynamically add listeners to it).
Of course, I could:
pass my event-dispatcher that implements the PSR interface and contains the Messenger bus call logic, but that's inconvenient because I have to either insert it manually in my services or bind my custom dispatcher in the “services > _defaults > bind” config with some unique variable name - from my point of view, this is very strange;
send events using the native event-dispatcher and then redirect them in the listener to the Messenger bus - too many steps for nothing.
I really like the approach that the Messenger component provides, which gives me the tools to manage all the routes (flows) of my events and leaves handlers (with no php attributes to configure) with events in the "I don't care" state.
I'm thinking about merging event-dispatcher and the Messenger bus and using the nice PSR interface in my service layer. This can be done by completely replacing the default/native event-dispatcher with an additional bus (with a basic middleware) of the Messenger component for synchronous native events and logic for choosing which messenger bus should be used for which events.
Yes, it seems very scary, but as a result, I will look at my code in a "My precious" way.
If you have your own vision, please write it in the comments.
P.S. Who has read this - have a good day and a bigger salary.
How crazy is it?
It can be done.
0%
No, it's better not to do this.
0%
@currentUserSays I don't care at all. But I love you very much ❤️.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I'm trying to make my service layer more clear and pretty looking. To do this, I want to make my code more indifferent to its neighbors.
Something like this:
#region TLDR
Symfony gives 2 tools for managening events :
Synchronous events/messages can be handled by both of them. I know that the Messenger component has more advanced logic, like middleware - which can be turned off and leave only a sender/receiver logic, but in general, it can do the same job, as the event-dispatcher.
After I installed the Messenger component, I was a bit confused, now I don’t need event-dispatcher, because I have a similar tool.
From my perspective, it’s better to use “service layer” interfaces or PSR interfaces in dependencies instead of some framework stuff. Symfony makes it possible to use the PSR interface for event-dispatcher and that's pretty cool, but I can't:
Of course, I could:
I really like the approach that the Messenger component provides, which gives me the tools to manage all the routes (flows) of my events and leaves handlers (with no php attributes to configure) with events in the "I don't care" state.
I'm thinking about merging event-dispatcher and the Messenger bus and using the nice PSR interface in my service layer. This can be done by completely replacing the default/native event-dispatcher with an additional bus (with a basic middleware) of the Messenger component for synchronous native events and logic for choosing which messenger bus should be used for which events.
Yes, it seems very scary, but as a result, I will look at my code in a "My precious" way.
If you have your own vision, please write it in the comments.
P.S. Who has read this - have a good day and a bigger salary.
2 votes ·
Beta Was this translation helpful? Give feedback.
All reactions