Комментарии 20
Я правильно понимаю, что один сервис отвечает за обработку всех исключений, кто бы их ни кинул?
В данном примере — да, но ничто не мешает сделать сервисы для каждой группы исключений и заинжектить их в основной сервис.
То есть если я пишу бандл, которы хочет как-то реагировать на исключения, я должен реализовать сервис, подходящий под ваши нужды и перед использованием попросить вас заинжектить его и дёрнуть в контроллере?
Нет, не так. В своем посте я писал не про бандл, а про обычное приложение. Само собой, для бандла или компонента нужно реализовывать листенер. На мое мировоззрение в этом плане немало повлияло общение с разработчиками Симфони (IRC и Stackoverflow), в частности здесь мне отвечали на этот вопрос.
НЛО прилетело и опубликовало эту надпись здесь
Конечно. Описанный подход ломает модульность, увеличивает связанность, усложняет поддержку, убивает идею бандлов.
Идея бандлов нужна только для распространения кода, а не для конкретного приложения. Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2
Мы говорим о бизнес-логике приложения или об уровне представления? Я вижу тут обработку исключений на уровне контроллера и общего хендлера. И чем обработка исключений через ExceptionController отвязывает нас от фреймворка? Скорее, наоборот, привязывает намертво: события – это простые value-объекты, и их можно переиспользовать, а перегруженный ExcetpionController – это прямое наследие симфони.
У меня бизнес-логика реализованна на уровне бандлов и приложение собирается из таких вот внутренних бандлов. Благодаря этому, над моим приложением работает кучас разработчиков, не мешая друг другу, мне просто тестировать все компоненты приложения по отдельности и я могу собирать на разных инстансах разные конфигурации приложения(одно приложение умеет работать с платежами и пользователями, другое только с платежами, третье только с пользователями и так далее).
А вот этого:
Я прямо таки откровенно не понял.
А вот этого:
Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2
Я прямо таки откровенно не понял.
То же самое можно сделать не используя бандлы, в чём аргумент?
Попробуй теперь перевезти свой код из папочки `src/` на другой фреймворк. Там не просто какой-нибудь слой адаптеров поправить, там придется перелопатить иерархию директорий. Если есть желание разбить два компонента — один для работы с юзерами и один для работы с платежами, ничего не мешает это сделать просто вынеся их в разные директории, для этого не нужны разные бандлы.
Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2
Я прямо таки откровенно не понял.
Попробуй теперь перевезти свой код из папочки `src/` на другой фреймворк. Там не просто какой-нибудь слой адаптеров поправить, там придется перелопатить иерархию директорий. Если есть желание разбить два компонента — один для работы с юзерами и один для работы с платежами, ничего не мешает это сделать просто вынеся их в разные директории, для этого не нужны разные бандлы.
Бизнес логика самого приложения вообще не должна быть в каком-либо бандле
Бизнес-логика в либе, а бандл — интеграция либы с Симфони. Разделять их или нет на отдельные пакеты композера, держать в одном дереве каталогов или нет и т. п. — может быть хорошо в одном случае и плохо в другом.
Единственное, что могу сказать: данный подход описан для обычного приложения, а не для бандла. Например, я этот перехватчик использую в своем http api, когда нужно отреагировать на определенную ошибку на фронтенде. В противном случае, у меня будет возвращаться ошибка 500 для всех исключений, которые мое приложение выбрасывает (кстати, их немного).
А по поводу вашего утверждения я согласен.
А по поводу вашего утверждения я согласен.
В этом кейсе использование событий очень даже хорошее решение. На одном из проектов попробовал такую архитектуру: приложение ничего не знает о том как обрабатывать исключения и занимается лишь их бросанием, а уже middleware в зависимости от разных факторов, занимается конвертированием исключений в различное представление, будь то json или xml.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Symfony2 перехватчик исключений с помощью сервисов или как избежать использования Event Listener