8000 [Messenger] Introduce handle method on MessageBusInterface instead of Trait · Issue #29428 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content
[Messenger] Introduce handle method on MessageBusInterface instead of Trait #29428
Closed
@ghost

Description

Description
This issue is related to the PR #29167 and #28983, which I believe does not solve the recent changes in the Messenger component.

There should be a handle method on the MessageBusInterface itself, which I believe is a better solution than introducing a Trait. Using said Trait comes with a set of limitations that I believe can be solved by adding previous functionality back to the MessageBusInterface.

  • Using the Trait forces you to use $messageBus as the property name, before you were able to name it to your liking, such as $commandBus or $queryBus, which makes more sense from a semantical point of view.
  • The Symfony Profiler component does no longer show the count of messages handled by a bus, due to binding now being impossible, thanks to the enforced property naming in the handle() method of the Trait.
  • It seems odd to inject a MessageBusInterface, for instance in a Controller, which then also needs to use HandleTrait. It should be as simple as calling $this->queryBus->handle(new Query());
    (Edit: Alternatively I have to create my own QueryBus that uses the HandleTrait, which should not be needed since my Framework already offers a working Bus and also causes confusion where that Trait should actually be used.)
  • Introducing a Trait still does not resolve the issue of having no return type. The same issue still remains, but now more problems have resulted due to the change.

I understand the issue with return types, as discussed in the PR mentioned above, however the current implementation seems to be too focused on solving a specific issue, which might not need to be solved at all.
Regarding the explanation of implementing your own QueryBus from this PR, again, I believe this is going out of the way of how things should work. I think sacrificing not having a return type on the handle method is an acceptable trade-off here.

Example
I propose to (re)introduce a handle() method on the MessageBusInterface, which will solve the issues mentioned above, as well as make it simpler to use. The HandleTrait can be removed again, and the logic from within the handle method would be moved back into the MessageBus implementation.

interface MessageBusInterface
{
    /**
     * Dispatches the given message.
     *
     * @param object|Envelope $message The message or the message pre-wrapped in an envelope
     */
    public function dispatch($message): Envelope;

    /**
     * Handles the given message.
     *
     * @param object|Envelope $message The message or the message pre-wrapped in an envelope
     *
     * @return mixed The value returned by the handler
     */
    public function handle($message);
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    MessengerRFCRFC = Request For Comments (proposals about features that you want to be discussed)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0