А если в сервисе используется 2 шины, то bus1 и bus2 ?))

я бы на самом деле, наверное, это порешал через тэги и компайлер-пасс. типа помечаешь свой сервис "это клиент мессадж баса, ему нужна такая-то шина"

я до компайлер-паса еще не дорос)

тогда уже да, называть по-разному

Может сразу придти к конвеншну $messageBus, $commandBus и код читабельнее ;)

это гораздо проще, чем кажется. там будет 20 строк простого кода из туториала

не, хочу диктатуру) чтобы быть уверенным, что туда не придёт другой сервис... а имена в любом случае можно писать осмысленно

не диктатура, тип то тоже нужно описать, а какая разница, какая имплементация придет.

он не читабельнее, это неявное соглашение, которое все разрабы обязаны соблюдать. назвал он свою переменную иначе - и все развалилось, даже ошибку не найдешь, просто твой сервис публикует в другую шину

я выше лучше вариант предложил с тэгами

https://symfony.com/doc/current/service_container/compiler_passes.html

я выше лучше вариант предложил с тэгами

Каким образом это решить тэгами?

тэггировать свои сервисы указанной шиной. чтобы избавить от этого знания класс сервиса, что снаружи пришло, туда и паблишим

А если 2 шины нужно в сервисе?

- { name: bus.client, bus: events } - { name: bus.client, bus: app }

я бы руками расставил в ямле

и клиентам бандла замучаешься объяснять что куда биндить. а так "укажи зависимостью FooBus и все заработает"

так он не хочет описывать это в ямле, типа это поведение за пределы бандла пойдет

в общем создал наследника от MessageBus, но при попытке прописать в command.bus получаю ошибку: Cannot replace arguments for class "TheSite\Base\Component\CommandBus" if none have been configured yet. подебажил - это в MessengerPass он заменяет параметры-middleware's как победить? что тут не так? $services ->set('command.bus', CommandBus::class) ->args([]) // это я уже после ошибки добавил - не помогло ->tag('messenger.bus');

Описать 2-3 шины один раз, и все. Тут тоже самое написано, правда не через bind https://symfony.com/doc/current/service_container/autowiring.html#dealing-with-multiple-implementations-of-the-same-type

Зачем наследовать, есть же декоратор

это тоже еще не в теме) можно подробнее/пример?

это тоже еще не в теме) можно подробнее/пример?

это тоже еще не в теме) можно подробнее/пример?

Добавил в комент пример конфига на ямле. З.Ы. messenger компонент, сам создает бинд на аргументы по именам шин. https://symfony.com/doc/current/messenger/multiple_buses.html query.bus: autowireable with MessageBusInterface $queryBus;

хм. я правильно понимаю, что теперь "мои шины" не будут по сути шинами(без тега messenger.bus и вообще) а просто как обычный сервис с зависимостью в виде шины - верно?

хм. я правильно понимаю, что теперь "мои шины" не будут по сути шинами(без тега messenger.bus и вообще) а просто как обычный сервис с зависимостью в виде шины - верно?

Не понял. Это два класса обертки над шинами, что б у каждой шины был свой класс, шины остаются которые и были )

шины то остаются, но их уже нет в зависимостях напрямую - там уже только обёртка, которая уже не шина(без тега, в конструкторе без middlewares)

ну типа это не системные шины, ты их не увидишь в контейнере с тегом messenger.bus то есть зависимые вещи, не будут зависеть от шины вообще, они просто зависят от "обычного" сервиса, который зависит от шины, но сам в системе как шина не фигурирует

ну типа это не системные шины, ты их не увидишь в контейнере с тегом messenger.bus то есть зависимые вещи, не будут зависеть от шины вообще, они просто зависят от "обычного" сервиса, который зависит от шины, но сам в системе как шина не фигурирует

Почему не увидишь? ) Шины надо сначала всеравно описать в конфиге, и они должны существовать в системе. Весь смысл в том, что б существующую шину обернуть к конкретный класс, что бы работайл автовайринг.

как шины, тут будут описаны всё те же command.bus / MessageBus а декораторы - уже не описываются таким образом - у них нет тега "messanger.bus" и, самое главное - ты им не сможешь middlewares прописать - их уже нет в конструкторе

мидллвари прописываются в конфиге

да, но кому? где тут вход для middleware?

Туда уже передается шина с мидлварями )

так и я про то же: то есть декроатор - уже не шина, в привычном понимани, которую можно сконфигурять как шину - уже низя... это просто сервис который зависит от шины... или я чего не того?)

так и я про то же: то есть декроатор - уже не шина, в привычном понимани, которую можно сконфигурять как шину - уже низя... это просто сервис который зависит от шины... или я чего не того?)

К шине command.bus прописываются миддлвари. Компонент автоматически создаст шину command.bus с мидлварями, мы берем эту готовую шину, и пихаем в декоратор

с этим понятно. но декоратор - просто от неё зависит, сам не являясь шиной... в общем это я для понимаю просто)

Декоратор все вызовы, напрямую, передает в конкретную шину, и больше ничего )

это тоже понятно. но, при этом, только я знаю что он работает как шина - для системы(по конфигам framework.messenger.buses) - он уже не шина)))

и middleware ему отдельно уже тоже не подсунуть - только декорируемой "настоящей" шине

я про суть)

Суть в том что это декоратор )

вот и поговорили) я ж изначально об этом)