EventualCommandBus или публикация в хендлере?
EventualCommandBus или публикация в хендлере?
Возникла потребность реализовать диспетчеризацию событий из слоя приложения.
Вижу 2 пути для реализации:
1. сделать декоратор EventualCommandBus, который будет магическим образом получать событие из хендлера и отправлять событие на обработку или
2. использовать диспетчер прямо в хендлере
У обеих подходов вижу и + и -
У 1 очевидный недостаток (скорее, сложность), это получение события. Но у меня хендлер возвращает объект CommandResult, в нем можно сделать поле для записи события, и в шине его извлекать. Или можно придумать еще кучу способов для этого. И 2 недостаток это, что придется делать такой-же EventualQueryBus.
Но явное преимущество в том, что публикация события необязательно должна происходить в хендлере. К примеру, ValidationBus, в случае провала валидации, сам создает объект CommandResult, и декоратор сможет успешно обработать событие валидации.
В общем, хотел бы услышать ваше мнение и, если поделитесь, посмотреть примеры.
Вижу 2 пути для реализации:
1. сделать декоратор EventualCommandBus, который будет магическим образом получать событие из хендлера и отправлять событие на обработку или
2. использовать диспетчер прямо в хендлере
У обеих подходов вижу и + и -
У 1 очевидный недостаток (скорее, сложность), это получение события. Но у меня хендлер возвращает объект CommandResult, в нем можно сделать поле для записи события, и в шине его извлекать. Или можно придумать еще кучу способов для этого. И 2 недостаток это, что придется делать такой-же EventualQueryBus.
Но явное преимущество в том, что публикация события необязательно должна происходить в хендлере. К примеру, ValidationBus, в случае провала валидации, сам создает объект CommandResult, и декоратор сможет успешно обработать событие валидации.
В общем, хотел бы услышать ваше мнение и, если поделитесь, посмотреть примеры.
Re: EventualCommandBus или публикация в хендлере?
у меня есть в проекте event bus. везде где надо диспетчить события, я просто отправляю в нее событие $eventBus->handle($event).
Внутри проекта мы можем повесить на событие такой же хэндлер как и в шине команд. Также шина событий имеет мидлварь, которая все события дополнительно отправляет в рэббит для обработки другими сервисами.
Внутри проекта мы можем повесить на событие такой же хэндлер как и в шине команд. Также шина событий имеет мидлварь, которая все события дополнительно отправляет в рэббит для обработки другими сервисами.
Re: EventualCommandBus или публикация в хендлере?
Код: Выделить всё
$eventBus->handle($event)
Re: EventualCommandBus или публикация в хендлере?
это отправка события в шину. Все аналогично шине команд, в рамках паттерна message busNex-Otaku писал(а): ↑2018.01.20, 11:14Это создание события или его обработка?Код: Выделить всё
$eventBus->handle($event)
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: EventualCommandBus или публикация в хендлере?
Шина разве должна возвращать результат?!
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: EventualCommandBus или публикация в хендлере?
https://habrahabr.ru/post/347908/Грег Янг четко обозначает свою позицию по этому вопросу: "Должен ли обработчик команды всегда возвращать void? Нет, список ошибок или исключение может быть результатом выполнения". Обработчик может возвращать результат выполнения операции. Он не должен заниматься работой Query — поиском данных, что не значит, что он не может возвращать значение.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: EventualCommandBus или публикация в хендлере?
Во, спасибо! Почитаю на досуге)
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: EventualCommandBus или публикация в хендлере?
У меня шина всегда возвращает результат.
Результатом является объект класса CommandResult, который описывает результат операции над ресурсом.
Результатом операции может быть, например, success, fail, created, pending (как раз пригодится для асинхронной шины) итп.
И, в добавок, в объект результата можно передать полезную нагрузку и получить через CommandResult::getPayload().
Меня такое решение вполне устраивает.
Если отказаться от такого объекта, то придется морочиться с обработкой исключений, что немного усложняет работу.
В моей реализации, результат можно сконвертировать в массив (CommandResult::toArray()) и просто отдать клиенту (очень упрощает работу с REST контроллерами).
Результатом является объект класса CommandResult, который описывает результат операции над ресурсом.
Результатом операции может быть, например, success, fail, created, pending (как раз пригодится для асинхронной шины) итп.
И, в добавок, в объект результата можно передать полезную нагрузку и получить через CommandResult::getPayload().
Меня такое решение вполне устраивает.
Если отказаться от такого объекта, то придется морочиться с обработкой исключений, что немного усложняет работу.
В моей реализации, результат можно сконвертировать в массив (CommandResult::toArray()) и просто отдать клиенту (очень упрощает работу с REST контроллерами).