Laravel Controllers: Concept of Service and Actions
HTML-код
- Опубликовано: 30 июл 2024
- What should Laravel controllers look like? Controllers are bridges between route, logic and view. Controllers should have a minimum of code. Each class has its own responsibility - Serveices and Actions are used for this.
laravelcontrollers # laravel # cutcode
❗️❗️❗️How to make complex sites in laravel? It's easy with cutcode!
Support my project - cutcode.ru/
Buy me coffee - buymeacoffee.com/cutcode
🤖🤖🤖My assistant Taylor is ready to give you a present. Pick up here - cutcode.ru/chat-bot
-------------------------------------------------- -------------------------------
⏰ Timecodes:
00:00 Introduction and some theory
00:56 Example with Actions and Services
01:40 What's the Difference Between Actions and Services
02:12 Create Action
04:20 Create Service
Friends, I welcome everyone to the Cutcode channel! In continuation of the video on Service Container, I want to talk about another concept that did not come from Laravel. But it is also popular among Laravel developers. If you use it, you will always be understood and in general it will be good practice.
Briefly about the point: in a good application, each class should have its own area of responsibility. If we are talking about a controller, then it should not be full of a huge canvas of code. The controller is such a bridge between the route, logic and view or responsiveness. Therefore, the logic must be separated and put into separate classes. Consider an example again from the admin. panels from Laravel courses from scratch. I will definitely add the link to the description.
So in our example we have a resource controller admin user, the Update method. There is some logic here with updating the user, we update the users, do some password manipulations and synchronize the user's roles. What's the point? There is also a resource controller and a store method that creates a user and here, by and large, the same functionality, the same logic. That is, we will do two duplicates of the code already here. Plus, how can you test this whole moment? That is, during unit tests, we must also create a third take, where we will also transfer all this logic and test there. This approach is not good and the concept of Actions and Service can come to our rescue. What is the actual difference between them? If we take Actions, then it is very similar to Laravel Jobs, that is, if we open Jobs in Laravel, then we have a Handle method that performs any one logical action. It's the same with Action, and as the name suggests, this is one action. That is, we create an action class and it must have a Handle method that will perform this action. Let's see an example.
-------------------------------------------------- -------------------------------
📹 share this video with your friends:
• Laravel контроллеры: к...
🔔 subscribe to the RUclips channel: / @cutcoderu
📼 Laravel course from scratch:
• Курс по Laravel 8 обуч...
Laravel Controllers: Concept of Service and Actions
-------------------------------------------------- -------------------------------
🔗 our website: cutcode.ru/
📷 our instagram: / cutcoderu
👏👏👏спасибо
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?
Да
Вопрос. Чем данный метод сервисов и экшенов лучше размещения логики в самой модели?
Ведь по сути как мне кажется лучше ж не создавать дополнительный сервис, а сразу вызвать метод из модели, разве нет?
Все зависит от ситуации, нельзя просто взять концепцию и использовать ее всюду! Как правило экшн контроллера выходит логикой за одну модель да и модель делать жирной не лучшая идея, думаю вы поняли о чем я в целом
хыхы я сервисы использовал, а про екшены не слышал
😒