Нормлаьно ли оборачивать comandBus->handle в try catch?

Нормлаьно ли оборачивать comandBus->handle в try catch?

смотря зачем)

Нормлаьно ли оборачивать comandBus->handle в try catch?

и смотря какая шина)

вот у меня есть операция восстановления пароля по секретной ссылке - я хочу в контроллере обработать, запрос создать, команду и закинуть ее в шину. Ну и отлавливать исключения чтобы вернуть соответсвующую вьху...ну а если всё ок, то успшеную вьюху

а что за шина у тебя? или самописное?

а что за шина у тебя? или самописное?

самописный

а какая разница?

хотя хз в пакете папка symfony есть...

но там два класса всего

CommandHandlerCollectorPass и ContainerAwareCommandBus

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

вот у меня есть операция восстановления пароля по секретной ссылке - я хочу в контроллере обработать, запрос создать, команду и закинуть ее в шину. Ну и отлавливать исключения чтобы вернуть соответсвующую вьху...ну а если всё ок, то успшеную вьюху

норм

не вижу проблем

я еще думал про то, чтобы возвращать результат операции, как вчера обсуждали

но тут тоже не очень красиво, т.к. слегка god-object'ово

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

блин человек спросил про try/catch

а вы ему про год обджекты и возврат значений)

ну так очень похоже на мой вчерашний вопрос и последовавший срач)

на самом деле имхо норм)

вот у меня есть операция восстановления пароля по секретной ссылке - я хочу в контроллере обработать, запрос создать, команду и закинуть ее в шину. Ну и отлавливать исключения чтобы вернуть соответсвующую вьху...ну а если всё ок, то успшеную вьюху

по хорошему шина команд либо асинхронна, и ничего не может вренуть, даже исключений (ибо операция выполняется после выхода из функции). Либо ты забиваешь и делаешь так как тебе хочется

блин человек спросил про try/catch

да тут в чате последнее время сформировалась екта любителей ифов и возвращения булевых значений

блин человек спросил про try/catch

а разве для чата не привычно разводить простые вопросы в чуть ли не мордобои?)

да тут в чате последнее время сформировалась екта любителей ифов и возвращения булевых значений

шина ничего не должна возвращать

но смысл "командного автобуса" в том что закинул же и забыл)

да я про это

твой сценарий чуть с "закинул и забыл" не дружит) как и мои

но смысл "командного автобуса" в том что закинул же и забыл)

ты можешь подписаться на события

если что-то пойдет не так

но нафига

ты можешь подписаться на события

ну вот да тут оч простйо кейс, я что то решил что события оверхед будут + я не понял как из листенера события вренуть вьюху(и куда вообще ее возвращать)

@fes0r вот ты бы вместо сервисбасов юзал просто максимально простые делегирующие сервисы + логику в сущностях?

ну вот да тут оч простйо кейс, я что то решил что события оверхед будут + я не понял как из листенера события вренуть вьюху(и куда вообще ее возвращать)

listener + longpolling\websocket\чотамщасмодно?

не совсем понял причем тут инфрастркутурные штуки) вот у меня улетела событие ошибки в евентБас его поймал обработчик и обработал. кому он должен отдать htttResponse?

да вроде никому - никак ты это в контроллер не пробросишь без костылей

@fes0r вот ты бы вместо сервисбасов юзал просто максимально простые делегирующие сервисы + логику в сущностях?

да, не вижу смысла в шинах если тебе нет профита от асинхронной обработки команд

да, не вижу смысла в шинах если тебе нет профита от асинхронной обработки команд

я вот тоже об этом думаю часто

но нужен баланс

какой к черту баланс?

у тебя есть распределенная система - или нет

если нет - нет смысла заморачиваться с шинами и асинхронщиной

есть - у тебя выбора нет)

если нет - нет смысла заморачиваться с шинами и асинхронщиной

некоторый смысл имеется - мы получаем более тонкие контроллеры + можем менять поведение запрсоа не лазяя в контроллер(просто указывая другой хендлер)

какой к черту баланс?

имел ввиду не это, но сморозил все равно чушь, забей

некоторый смысл имеется - мы получаем более тонкие контроллеры + можем менять поведение запрсоа не лазяя в контроллер(просто указывая другой хендлер)

от реализации зависит как у тебя оно работает?

некоторый смысл имеется - мы получаем более тонкие контроллеры + можем менять поведение запрсоа не лазяя в контроллер(просто указывая другой хендлер)

не тоньше чем с сервисами для оркестрации которые работают синхронно

по поводу изменения поведения "не влязя в контроллер" - опять же application level сервисы

так что нет - смысла нет никакого

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

по поводу изменения поведения "не влязя в контроллер" - опять же application level сервисы

поясни, пожалуйста

поясни, пожалуйста

ну контроллер только дергает сервис, ничего менять в контроллере не надо. Ровно так же как и с шиной

да, тут не поспоришь... пока я ещё думаю над аргументами :D не холивара ради и не в защиту шин

по поводу изменения поведения "не влязя в контроллер" - опять же application level сервисы

Так сервис все равно надо вызвать же в контроллере

И поменять его на другой в случае чего

Так сервис все равно надо вызвать же в контроллере

так шину тоже надо вызвать в контроллере. Так команду надо всеравно собрать

И поменять его на другой в случае чего

типа подменить "обработчика" команды? а тебе это хоть раз нужно было?)))

сомневаюсь

Также же

Бойся php 7.3?

Ок

Шина всегда одна и та же(Как и команда которую мы кидаем туда). А если мы ее не юзаем то надо разные сервисы в зависимости от нужного действия

Прошу прощения)

Шина всегда одна и та же(Как и команда которую мы кидаем туда). А если мы ее не юзаем то надо разные сервисы в зависимости от нужного действия

с точки зрения связанности одна фигня

с точки зрения связанности одна фигня

плюсую, команды разные

типа подменить "обработчика" команды? а тебе это хоть раз нужно было?)))

Пока что нет!

ну вот и мне нет)

либо мы создаём разные команды и кидаем в шину, либо дёргаем разные сервисы

сообщения, все дела

А как быть если я талантлив, а приходится делать сайты на вордпресс, или ещё хуже на наткет?

Я хочу лару юзать

Я хочу лару юзать

у тебя какие-то очень примитивные представления о "таланте"

Братья вообще можете в кратце описать плюсы ООП

Братья вообще можете в кратце описать плюсы ООП

более внятная модель декомпозиции систем

изоляция, управление зависимостями, сокрытие информации.

на этом все

Ой

ФП - примерно то же самое но "вроде бы" чуть более формализовано и потому сложнее)

Я просто завис где то там

В 2005

Да много кто

В 2005

Ооп-то постарше будет на четверть века)

я его в РО отправил на денек

ФП - примерно то же самое но "вроде бы" чуть более формализовано и потому сложнее)

А на фп вообще есть примеры корпоративных приложений интересно успешные

Я вот хз как бы потрогать его

На хаскелле найдешь что угодно

А на фп вообще есть примеры корпоративных приложений интересно успешные

ченить на эрланге - вполне