Pull to refresh

Comments 20

Я правильно понимаю, что один сервис отвечает за обработку всех исключений, кто бы их ни кинул?
В данном примере — да, но ничто не мешает сделать сервисы для каждой группы исключений и заинжектить их в основной сервис.
То есть если я пишу бандл, которы хочет как-то реагировать на исключения, я должен реализовать сервис, подходящий под ваши нужды и перед использованием попросить вас заинжектить его и дёрнуть в контроллере?
Нет, не так. В своем посте я писал не про бандл, а про обычное приложение. Само собой, для бандла или компонента нужно реализовывать листенер. На мое мировоззрение в этом плане немало повлияло общение с разработчиками Симфони (IRC и Stackoverflow), в частности здесь мне отвечали на этот вопрос.
В итоге мы получаем смешение подходов и еще большую путаницу при поддержке: бандлы, которые мы подключаем используют одну модель, приложение (я так понимаю, состоящее из одного бандла) имеет другую. Либо так, либо мы сразу говорим о том, что приложение не подразумевает расширения.
Расширение можно делать очень просто — изменяя код. В случае с third-party библиотеками ты не можешь менять их код, поэтому прибегают к разным подходам, в т.ч. к ивент-модели. Но когда ты можешь менять код и этот код не будет работать вне твоего приложения, нужно делать наиболее прямо.
UFO just landed and posted this here
Конечно. Описанный подход ломает модульность, увеличивает связанность, усложняет поддержку, убивает идею бандлов.
Идея бандлов нужна только для распространения кода, а не для конкретного приложения. Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2
Мы говорим о бизнес-логике приложения или об уровне представления? Я вижу тут обработку исключений на уровне контроллера и общего хендлера. И чем обработка исключений через ExceptionController отвязывает нас от фреймворка? Скорее, наоборот, привязывает намертво: события – это простые value-объекты, и их можно переиспользовать, а перегруженный ExcetpionController – это прямое наследие симфони.
Уровень предстваления твоего приложения входит в рамки твоего приложения. События привязывают тебя к symfony/event-dispatcher, сервис ни к чему тебя не привязывает, а контроллер это адаптер.
Контроллер не меньше завязан на симфони, чем диспетчер. Если ты отвязываешься от симфони, тебе надо реализовать DI, контроллер, респонс. В случае с диспетчером – диспетчер.
Как я сказал, контроллер — это адаптер.
У меня бизнес-логика реализованна на уровне бандлов и приложение собирается из таких вот внутренних бандлов. Благодаря этому, над моим приложением работает кучас разработчиков, не мешая друг другу, мне просто тестировать все компоненты приложения по отдельности и я могу собирать на разных инстансах разные конфигурации приложения(одно приложение умеет работать с платежами и пользователями, другое только с платежами, третье только с пользователями и так далее).
А вот этого:
Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2

Я прямо таки откровенно не понял.
То же самое можно сделать не используя бандлы, в чём аргумент?

Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2


Я прямо таки откровенно не понял.


Попробуй теперь перевезти свой код из папочки `src/` на другой фреймворк. Там не просто какой-нибудь слой адаптеров поправить, там придется перелопатить иерархию директорий. Если есть желание разбить два компонента — один для работы с юзерами и один для работы с платежами, ничего не мешает это сделать просто вынеся их в разные директории, для этого не нужны разные бандлы.
Бизнес логика самого приложения вообще не должна быть в каком-либо бандле


Бизнес-логика в либе, а бандл — интеграция либы с Симфони. Разделять их или нет на отдельные пакеты композера, держать в одном дереве каталогов или нет и т. п. — может быть хорошо в одном случае и плохо в другом.
Единственное, что могу сказать: данный подход описан для обычного приложения, а не для бандла. Например, я этот перехватчик использую в своем http api, когда нужно отреагировать на определенную ошибку на фронтенде. В противном случае, у меня будет возвращаться ошибка 500 для всех исключений, которые мое приложение выбрасывает (кстати, их немного).

А по поводу вашего утверждения я согласен.
UFO just landed and posted this here
Необрабатываемое бизнес-логикой исключение это и есть ошибка 500.
В этом кейсе использование событий очень даже хорошее решение. На одном из проектов попробовал такую архитектуру: приложение ничего не знает о том как обрабатывать исключения и занимается лишь их бросанием, а уже middleware в зависимости от разных факторов, занимается конвертированием исключений в различное представление, будь то json или xml.
Sign up to leave a comment.

Articles