1. В экшен из контроллера лучше передавать дто, а не массив. Поскольку такой подход более типизирован. Ну и идэешке проще будет подсветить то, что есть в дто. А массив - это черный ящик по сути. 2. Сервисы тоже должны отвечать за одну ответственность. Вот экшен также выступает в роли контроллера (в рамках грасп, а не эмвиси) и распределяет выполнение сервисов. Вижу код многих чуваков, которые в сервис пихают все, что можно, то есть сервис состоит из разных методов, связанных только одной моделью. это крайне не правильно. с точки зрения того же срп. Если логика экшена сложнее простого сохранения юзера, то, например, должны быть сервисы (отдельные классы) обработки данных юзера перед сохранением, само сохранение, логирование результатов операции и т.д.
@@CutCodeRu 2) Не совсем пойму разницу actions и services тогда. Если services также должны отчечать за одну отвественность. В чем его отличие от actions?
@@user-uy7sc8sf5o Контроллер только принимает запрос и отдает вью. Экшин выполняет роль контроллера если бы он был раздутый. Ну и сервисы в них бизнеслогика. Я так понимаю
Те кто не понял сервис должен следовать единственной ответственности, но это не значит, что в нем должен быть один метод. Их может быть сколько угодно. Главное не нарушать принцип SOLID.
@@androidiosgameplay-anrad7256 думаю, вам/тебе следует перечитать про срп и мой коммент, в котором нет упоминания того, что класс должен содержать один метод.
Расскажи не про чистый код, А что делать ,когда приходишь на проект, а там контроллеры по 2000 строк, в которых модели в массивах сортируются, и связные данные так же массивами цепляются? Хочется чтобы все по классам было разложено, но фиг. И на рефактор времени не выделяют. А ещё неизвестно как это все работает, потому что из вьюх тоже запросы в базу есть. И рефактор контроллера фронт затрагивает, а во фронте ещё одна вьюха с 5000 строками и непонятным джаваскриптом в который значения переменных из пхп печатаются...
Повышать стоимость поддержки. Ежемесячно x1.28 Аргументируя состоянием системы - говнокод. Тогда заказчик быстрее смекнёт, что рефактор - очень полезная штука, которая бабки экономит
Я делаю так если код меняет состояние апп то он уходить в акшоны а если код просто считывает данные например из бд или выполняет какую операцию чтобы получить другой результат например сортирует, умножает …. То этот код уходит в сервис и не обязательно сервисов группировать по название модели
Вопрос. Чем данный метод сервисов и экшенов лучше размещения логики в самой модели? Ведь по сути как мне кажется лучше ж не создавать дополнительный сервис, а сразу вызвать метод из модели, разве нет?
Все зависит от ситуации, нельзя просто взять концепцию и использовать ее всюду! Как правило экшн контроллера выходит логикой за одну модель да и модель делать жирной не лучшая идея, думаю вы поняли о чем я в целом
1. В экшен из контроллера лучше передавать дто, а не массив. Поскольку такой подход более типизирован. Ну и идэешке проще будет подсветить то, что есть в дто. А массив - это черный ящик по сути.
2. Сервисы тоже должны отвечать за одну ответственность. Вот экшен также выступает в роли контроллера (в рамках грасп, а не эмвиси) и распределяет выполнение сервисов. Вижу код многих чуваков, которые в сервис пихают все, что можно, то есть сервис состоит из разных методов, связанных только одной моделью. это крайне не правильно. с точки зрения того же срп. Если логика экшена сложнее простого сохранения юзера, то, например, должны быть сервисы (отдельные классы) обработки данных юзера перед сохранением, само сохранение, логирование результатов операции и т.д.
1) Почему бы и нет
2) Совершенно верно)
@@CutCodeRu
2) Не совсем пойму разницу actions и services тогда. Если services также должны отчечать за одну отвественность. В чем его отличие от actions?
@@user-uy7sc8sf5o Контроллер только принимает запрос и отдает вью. Экшин выполняет роль контроллера если бы он был раздутый. Ну и сервисы в них бизнеслогика. Я так понимаю
Те кто не понял сервис должен следовать единственной ответственности, но это не значит, что в нем должен быть один метод. Их может быть сколько угодно. Главное не нарушать принцип SOLID.
@@androidiosgameplay-anrad7256 думаю, вам/тебе следует перечитать про срп и мой коммент, в котором нет упоминания того, что класс должен содержать один метод.
👏👏👏спасибо
Расскажи не про чистый код, А что делать ,когда приходишь на проект, а там контроллеры по 2000 строк, в которых модели в массивах сортируются, и связные данные так же массивами цепляются? Хочется чтобы все по классам было разложено, но фиг. И на рефактор времени не выделяют. А ещё неизвестно как это все работает, потому что из вьюх тоже запросы в базу есть. И рефактор контроллера фронт затрагивает, а во фронте ещё одна вьюха с 5000 строками и непонятным джаваскриптом в который значения переменных из пхп печатаются...
Все печально одним словом, но если на рефакторинг времени не выделяют то ответ никак)
Повышать стоимость поддержки. Ежемесячно x1.28
Аргументируя состоянием системы - говнокод. Тогда заказчик быстрее смекнёт, что рефактор - очень полезная штука, которая бабки экономит
В чем разница сервиса и экшена? Когда какой использовать?
Разные концепции, какой больше нравится в зависимости от ситуации, группа методов либо один, подход выбираете сами
Я делаю так если код меняет состояние апп то он уходить в акшоны а если код просто считывает данные например из бд или выполняет какую операцию чтобы получить другой результат например сортирует, умножает …. То этот код уходит в сервис и не обязательно сервисов группировать по название модели
Ну про Jobs я понял, что это очереди или queues, а что за Actions? где такое в документации?
добрый день! приглашаю в наш чат t.me/laravel_chat, там на вопросы отвечаем быстрее
Можно ли в Actions использовать метод __invoke?
Да
Вопрос. Чем данный метод сервисов и экшенов лучше размещения логики в самой модели?
Ведь по сути как мне кажется лучше ж не создавать дополнительный сервис, а сразу вызвать метод из модели, разве нет?
Все зависит от ситуации, нельзя просто взять концепцию и использовать ее всюду! Как правило экшн контроллера выходит логикой за одну модель да и модель делать жирной не лучшая идея, думаю вы поняли о чем я в целом
хыхы я сервисы использовал, а про екшены не слышал
😒