Ivan
Всем привет!) Кто что думает о том, если использовать подход command&query bus, но без bus, а объявляя обработчики прямо в DI контроллера? Например CreateUserCommandHandler или GetUserByIdHandler?
Null
Теряешь возможность легко sync на async потом переключить.
Null
Задача контроллера кинуть в шину данные. А дальше уже он не должен знать ,как именно сообщение будет обрабатываться.
Ivan
Почему вообще возник вопрос, так как первый из них у меня должен вернуть id пользователя, второй самого пользователя, в хендлерах это все отлично прописано в типизации, а если получить результат через bus, вернётся mixed, который еще придется проверять на тип.
Ivan
Возможно я что-то упускаю
Null
Не надо ничего получать из сообщения
Null
Сообщения отправляются в шину и все. Забывай о них.
Ivan
А как же query bus? С command bus понятно, там рекомендуют id генерировать самим до создания сущности, и тогда он известен
Юра
Почему вообще возник вопрос, так как первый из них у меня должен вернуть id пользователя, второй самого пользователя, в хендлерах это все отлично прописано в типизации, а если получить результат через bus, вернётся mixed, который еще придется проверять на тип.
https://symfony.com/doc/current/messenger/handler_results.html
Юра
Там есть пример с тайпхинтом резалта
Nikolay
Юра
Ну считай это сервис репозиторий который отдает результат какой-то
Юра
ДТО
Dmitriy
если асинхронщина не планируется то не надо никакой бас тащить
Kirill
Подскажите, пожалуйста, если в queryBuilder приджоинить сущность, это будет жадная загрузка?
$users = $qb->join('duties');
foreach ($users as $user) {
$user->getDuties(); //вот тут не будет запроса в БД?
}
Павел
Павел
Теряешь возможность легко sync на async потом переключить.
Только просто так это тоже фиг переключится, так как много ньансов будет.
Null
Ну хз. Если соблюдать все правила работы с мессенджером - всегда просто перекидывал с sync на async и бед не знал.
Главное правило - НЕ ПЕРЕДАВАЙ В СООБЩЕНИЕ СУЩНОСТИ, ПЕРЕДАВАЙ ID
Павел
Ну хз. Если соблюдать все правила работы с мессенджером - всегда просто перекидывал с sync на async и бед не знал.
Главное правило - НЕ ПЕРЕДАВАЙ В СООБЩЕНИЕ СУЩНОСТИ, ПЕРЕДАВАЙ ID
Ага только, если например надо вернуть id из одного обработчика и тут же отдать его другому в синхронном сообщении, то в асинке так не выйдет.
Null
Чойта. Цепочки можно строить и внутри шинок.
Null
Ларавельщики вон неистово гордятся, что у них роутер сообщений есть.
Null
$bus->dispatch(new CascadePostMessage)
Null
CascadePostMessageHandler - в конце своей работы $bus->dispatch(new AnotherPostMessage)
Павел
Null
Еще можно через енамы стейт-машин изобразить и на его основании делать цепочки.
Павел
Хэндлеры знают друг о друге - не то.
Павел
Хотя можно сделать третий, который вызовет синзронно эти два )))
Null
Ужоснах
Null
Не, ну тут смотреть надо. Если сообщение Post должно породить 100 изменений AnotherPost - чо бы и не явно?
Сергей
Ага только, если например надо вернуть id из одного обработчика и тут же отдать его другому в синхронном сообщении, то в асинке так не выйдет.
если вам так надо сделать, очевидно это будут синхронные действия.
Null
Я бы тут сделал один синхронный обработчик, который уже будет рулить кораблём.
Null
Главное голландский штурвал не изобразить.
Павел
если вам так надо сделать, очевидно это будут синхронные действия.
Согласен. Поэтому и говорю, что туда сюда синк асинк не всегда легко меняются.
Null
Согласен. Поэтому и говорю, что туда сюда синк асинк не всегда легко меняются.
В рамках одного Message должны быть такие действия.
Тогда в любой момент можно синк на асинк заменить.
Null
Никто же заставляет цепочку действий именно в рамках n сообщений мутить. Цепочку действий можно каким-нибудь другим сервисом осуществить.
Контролер лишь сообщает в шину, что ему требуется начать какой-то тех. процесс.
Сергей
кто то говорит о квери/команд басах, а кто то про мессенджер)
Павел
В рамках одного Message должны быть такие действия.
Тогда в любой момент можно синк на асинк заменить.
Ага только синк позволяет отдать ответ обратно и выдать на фронт сообщение, а асинк не может и надо городить уже какие то пост операции для оповещения пользователя о обратимости. Уже разные кейсы и разная работа. Ладно, спор ни о чем
Null
Ой да ладно. Можно подумать тут дофига цепочек споров именно "о чем" )
Павел
Ой да ладно. Можно подумать тут дофига цепочек споров именно "о чем" )
Но тут даже в теории не понятно к чему придем) вы так считаете, я так, делаем как нам удобно. Профита тоже не можем особо предоставить.
Dmitriy
по мне так не надо усложнять систему если от асинка не видно профита
Ivan
Всем спасибо за мнения!) Значит делать command/query handlers, но использовать их через DI кажется не сильно неадекватным решением?)
Dmitriy
нормальное решение
Павел
Всем спасибо за мнения!) Значит делать command/query handlers, но использовать их через DI кажется не сильно неадекватным решением?)
Шина это шина, command/query - это ... ну понятно. Можно делать вместе, можно раздельно. Как будто cqs не существовало без шины, и без мессенджера. Просто шина позволяет не роутить вручную в контроллере. Ну и иметь единую точку входа для её модификации. На сколько это неоспоримый и необходимый плюс - хз.
Nikolay
Вообще непонятно для чего для выборки какие то шины нужны, кажется усложнением на ровном месте
Павел
Вообще непонятно для чего для выборки какие то шины нужны, кажется усложнением на ровном месте
Роутить можно автоматом. Кинул в шину, не подключаешь вручную обработчик.
Nikolay
Роутить можно автоматом. Кинул в шину, не подключаешь вручную обработчик.
И как это из шины в контроллер попадает?
Павел
Хотя надо подкючать шину)))
Павел
Синхронная
Павел
Да собсвтенно все тоже самое.
$responseDto = $queryHandler($query)
$responseDto = $bus->dispatch($query)
Павел
Ну или не http дто, а просто
Nikolay
Мне больше нравится для выборок два варианта:
1. QueryService/Provider
2. GetAllUsers отдельные классы на запросы
Павел
Мне больше нравится для выборок два варианта:
1. QueryService/Provider
2. GetAllUsers отдельные классы на запросы
Ну тут как обычно на вкус и цвет.
Shokha
Добрый день!
Вот это часть как пишется на пхп файле?
Vlad
Пример же ниже в этой же стр.
Vlad
А ты смотрел билдер,какие там методы?
Shokha
А ты смотрел билдер,какие там методы?
Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator ?
Vlad
Вон ниже пример
Vlad
https://symfony.com/doc/current/routing.html#route-groups-and-prefixes
Vlad
На этой же стр
Shokha
ой блин я слепой уже)
Shokha
спасибо
artem
всем утро) sh: /var/www/vendor/bin/php-cs-fixer: not found где недоставил?
artem
Vite4eg
А ты его вообще поставил?
composer show
artem
А ты его вообще поставил?
composer show
vimeo/psalm 4.29.0 A static analysis tool for finding errors in PHP applications
artem
composer show | grep psalm
Сергей
а че ты фиксер запускаешь?)
Сергей
а показываешь псалм
Vite4eg
Псалм-то тут причем? Тебе ругается на отсутствие пакета php-cs-fixer
artem
его если мануально поставить то будет не больно?