RFC: Autowiring commands to handlers in Symfony 3.3+

[rosstuck]

Based on the new service discovery coming in Symfony 3.3, I'd like to add a naming convention based locator.

The idea is that we could use config like:

services:
    App\:
        resource: '../../src/{Handler}'
        tags: ['tactician.handler']

This would autowire all handlers into the DI container using their FQCN as service id (RegisterUserHandler).

The proposed new locator would automatically route a command with a FQCN like Foo\RegisterUser or Foo\RegisterUserCommand to Foo\RegisterUserHandler. We could pull that directly from the container/service locator and presto, it works.

Pros:

• The user has all of their correct mappings in 3 lines of config, much less config typing, especially since IDEs don't autocomplete the command class name in services.yml
• No more worrying about updating the command names in the services.yml after doing a rename on a command.
• Much simpler onboarding for those using autowiring.

Cons:

• Much magic, such auto, very wow.
• We definitely need to add a switch to make this optional.
• Mainly works in Symfony 3.3 and up.

Thoughts:

• We could add a naming inflector interface for this autowiring so folks can add in their own class name conventions.

While I'm only so-so on autowiring containers and generally avoid it, I think this is a feature that pro-autowiring folks would really enjoy.

Thoughts? Totally open to all config format/feature/implementation suggestions here. :)

[ogizanagi]

It'd be great if it's also flexible enough & configurable out of the box.
In my own projects, I declare commands, queries and handlers in dedicated Command, Query, Handler namespaces (it might seem redundant, but it helps well to keep my Application layer structured and not overwhelming).

E.g: Foo\Application\User\Command\RegisterUserCommand should be handled by Foo\Application\User\Handler\RegisterUserCommandHandler

[tyx]

IMO everyone have its own habits regarding stuff naming. As @ogizanagi said we need this very flexible to be used.

In our apps, we have not dedicated handlers for example, so it becomes difficult to make magic I guess ;)

[ogizanagi]

Note that in the yaml configuration shown in the description:

services:
    App\:
        resource: '../../src/{Handler}'
        tags: ['tactician.handler']

the tag could also be completely removed if we introduce a marker interface, thanks to the autoconfigure capabilities of sf 3.3.
Above all, it also means you don't to write anything specific to handlers in the DI configuration, but simply keep the defaults proposed by the framework recipe using flex to PSR-4 load the whole src/ directory, and have everything configured & autowired automatically.

A similar marker is under discussion for Twig runtimes, which currently don't have any interface either.

[mateuszsip]

This is the tough one.

In my project we use notation like this:
Foo\Application\User\RegisterUser\RegisterUser for command and:
Foo\Application\User\RegisterUser\RegisterUserHandler for command handler.
Plus marker interfaces.

We could add a naming inflector interface for this autowiring so folks can add in their own class name conventions.

Sounds great, with a few most popular implementations it can work really well.

If you need any help, I would be glad to.

[jvasseur]

If we add an handler interface maybe we could add a static method to it that returns the corresponding command to remove the need for an inflector.

[rosstuck]

We've experimented with marker interfaces in the early days of Tactician and it never really worked out, so they were removed and won't return in core, especially since a large number of folks will probably never use autowiring. That said, if folks want to build it themselves, I think we should make it possible for them. (it's already possible today by writing a custom HandlerLocator which isn't super hard)

…

On Jun 3, 2017 3:01 PM, "Jérôme" ***@***.***> wrote: If me add an handler interface maybe we could add a static method to it that gives the corresponding command to remove the need for an inflector. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI9TtxaBo32WT4lSoPdSPOb97LqVRD3ks5sAVkogaJpZM4Nol_P> .

[ogizanagi]

I think it's slightly different here. No need to be in the core. It'll only serve autoconfiguring purpose, which is a symfony thing, thus should only be in the bundle. This marker interface should not serve any other means.

[sgomez]

Besides, using a marker interface could be the best way to differentiate who wants to use autowiring or not.

[rosstuck]

Closing in favor of #60 and the PR #67.