O
Выдели в пакет общую часть и подключай к приложениям
@grandmotivator reacted to a message from @krupni (3)
Size: a a a
2020 May 01
O
Гуглите гит сабмодули. Каждый проект в своем гите, общая часть сабмодулем
@nex_otaku reacted to a message from @dan1ellz (-3)
NO
Сабмодули это костыль, от которого вреда гораздо больше, чем пользы. Лучше уж в приватный репозиторий общий код выносить и подключать через композер
OK
Нужен небольшой архитектурный хелп. Куда бы вынести код составления и отправки писем? Кейс такой — обновилось поле модели (статус платежа поменялся на "оплачен", например) и надо отправить на мыло соответствующее письмо. В модели метод типа onAfterPaymentConfirmed() мне кажется говном каким-то некрасивым. Кто как делает? Подобных ивентов у модели может быть куча, и если отправку не вынести, то кода там будет 100500, который там вроде бы и нафиг не нужен
A
Oleg Kuzmenko
Нужен небольшой архитектурный хелп. Куда бы вынести код составления и отправки писем? Кейс такой — обновилось поле модели (статус платежа поменялся на "оплачен", например) и надо отправить на мыло соответствующее письмо. В модели метод типа onAfterPaymentConfirmed() мне кажется говном каким-то некрасивым. Кто как делает? Подобных ивентов у модели может быть куча, и если отправку не вынести, то кода там будет 100500, который там вроде бы и нафиг не нужен
В отдельный сервис(процесс) через очереди, самый распространенный кейс
OK
В отдельный сервис(процесс) через очереди, самый распространенный кейс
Очереди и так юзаю. Подробнее насчет сервиса можно?
A
Oleg Kuzmenko
Очереди и так юзаю. Подробнее насчет сервиса можно?
В самом простом варианте это может быть просто фоновая консольная таска того же проекта, в более сложном это может быть отдельный сервис может быть даже на другом языке
OK
Чтобы засунуть в очередь таску на отправку письма — мне в приложении надо это письмо сформировать. Откуда оно должно формироваться? Делать в модели на каждом чихе $this->mailer->compose() — это какое-то гонево
A
Oleg Kuzmenko
Чтобы засунуть в очередь таску на отправку письма — мне в приложении надо это письмо сформировать. Откуда оно должно формироваться? Делать в модели на каждом чихе $this->mailer->compose() — это какое-то гонево
Нет формировать уже должен сервис, у приложения другая задача, оно должно просто сказать сервису - отправь юзеру такое то письмо
A
Oleg Kuzmenko
Чтобы засунуть в очередь таску на отправку письма — мне в приложении надо это письмо сформировать. Откуда оно должно формироваться? Делать в модели на каждом чихе $this->mailer->compose() — это какое-то гонево
И модель не должна ничего знать о письмах это не ее зона ответсвенности
OK
И модель не должна ничего знать о письмах это не ее зона ответсвенности
Логично, поэтому и спрашиваю
OK
Нет формировать уже должен сервис, у приложения другая задача, оно должно просто сказать сервису - отправь юзеру такое то письмо
Тогда в сервисе будет 100 методов по однотипной отправке писем, это тоже гонево
OK
А разные методы — потому что разные данные туда должны прилетать, которые мне в письме надо отправить
A
Oleg Kuzmenko
Тогда в сервисе будет 100 методов по однотипной отправке писем, это тоже гонево
Подождите зачем 100? методов?
A
Например у вас есть 5-10 шаблонов письма, вы "говорите" сервису отправь такой то шаблон, достаточно одного метода
OK
В разные шаблоны разные данные пробрасываются
OK
Это не просто письмо "спасибо вам", там куча персонализированной инфы
A
Ну это логично ) есть шаблоны, делаете билдер для шаблонов, а билдеру отдаете шаблон и нужную сущность, например при оплате заказа - шаблон подтверждения заказа и сущность заказа, при регистрации - шаблон нового юзера и сущность юзера
A
Сто методов городить ненадо, такой код невозможно будет поддерживать ) в мире ооп нужно оперировать интерфейсами
OK
Сто методов городить ненадо, такой код невозможно будет поддерживать ) в мире ооп нужно оперировать интерфейсами
Ну я немножко что-то в этом понимаю 😉