AH
Как минимум затем, что создание юзера - это поведение бизнес-логики. Ее туда стоит вынести, а отправка бродкаста вообще лучше в обсервер на событие
created модели Message.created модели Message.Size: a a a
2020 May 13
RK
Как минимум затем, что создание юзера - это поведение бизнес-логики. Ее туда стоит вынести, а отправка бродкаста вообще лучше в обсервер на событие
второе я так и сделал уже
RK
но тогда тем более не понятно))
RK
я создаю сервис что бы там вызвать тот же код)
AH
Смотри, если в проекте везде такая простая логика, то согласен, создание юзера еще можно обосновать для контроллера, но если есть где-то чуть более сложная, что очевидно нужно вынести, то лучше всё сделать по единому, скажем так, шаблону дабы не было солянки вида "это создаем здесь, а это - там".
DE
Про контроллеры и сервисы над сущностями и про методы ещё свой доклад накину.
VY
В случае "пришел" еще валидатор (форм реквест) должен запустить и проверить есть ли право это делать.
А так да, принял, проверил, вызвал сервис, вернул результат.
А так да, принял, проверил, вызвал сервис, вернул результат.
а если то, что отдавать в сервис, вынести в этом же контроллере в отдельный метод протектед?
d
Привет всем
AH
а если то, что отдавать в сервис, вынести в этом же контроллере в отдельный метод протектед?
Это уже толстый контроллер будет.
Опять же, задача контроллера - контролировать, а не выполнять.
Опять же, задача контроллера - контролировать, а не выполнять.
d
Такой вопрос, как грамотно реализовать передачу переменной в миделвеа, если я могу достать её только в контроллерах?
d
Если говорить про паттерны
ИЛ
Такой вопрос, как грамотно реализовать передачу переменной в миделвеа, если я могу достать её только в контроллерах?
Это странная задача
RK
Смотри, если в проекте везде такая простая логика, то согласен, создание юзера еще можно обосновать для контроллера, но если есть где-то чуть более сложная, что очевидно нужно вынести, то лучше всё сделать по единому, скажем так, шаблону дабы не было солянки вида "это создаем здесь, а это - там".
эх ладно, в целом я со всем солидарен кроме этих сервисов, если есть прям рабочий пример где без них никуда было бы круто посмотреть
d
ДУмал про состояние, но это как я понимаю для последовательности
DE
Как минимум затем, что создание юзера - это поведение бизнес-логики. Ее туда стоит вынести, а отправка бродкаста вообще лучше в обсервер на событие
created модели Message.Со стандартными событиями created нюанс в том, что если сохраняем Message в транзакции, то эвент может уйти, а потом транзакция отвалится.
d
ДУмал про реджестри, а это для класов сервисов и тд
AH
эх ладно, в целом я со всем солидарен кроме этих сервисов, если есть прям рабочий пример где без них никуда было бы круто посмотреть
Есть, но они под эгидой корпоративной тайны :)
d
Это странная задача
НУ а что сделать))
ИЛ
НУ а что сделать))
Ты уверен, что это то что ты хочешь?
d
ДУмал про то чтобы вынести в метод и заюзать его в миделвеа, но получается определённый лишний код