@@CutCodeRu Прежде всего о нахождении баланса между непосредственно выполнением задачи бизнес логики и наведением порядка, через повышение степени абстракции.
Очень похоже на porto, только без tasks, тут главное добавить правило что action не может вызывать другой action, дублирующую логику выносить на уровень тасков, иначе можно получить колбекхелл когда action вызывает др. Action, тот следующий и т. Д. Ещё я бы добавил, что action должен содержать бизнес логику и не иметь прямых зависимостей, а такие вещи как хранение, транспорт и отображение нужно выносить в соответствующие слои
Почитал коменты), где писали что повествование жесть, как по мне в целом все понятно объяснил, или выносим в папку actions, или в services(я так кстати и делаю), мне больше нравится логику в одном классе писать, ну само собой там не 2 тысячи строк в одном классе)) или в трейты, трейты используем только в том случае, когда будем этот трейты где-то ещё переиспользовать
Информативно, но как по мне в больших проектах где много бизнес логики сложно найти место где можно лаконично использовать экшин класс и чтоб он был красивым и маленьким как на видео,. Писать 10 экшин классов вместо 1-2 классов по 5 методов не самый лучший подход
Такой подход хорошо использовать в небольших проектах. Было бы здорово увидеть видео про DDD и Porto. К примеру в Yii 2 Есть возможность скомпоновать логику в модули, а не разбрасывать всё по папкам. Жалко, что в Laravel из коробки такого нет.
Почему бы не хранить взаимодействие с другими сервисами в директории Clients? Тогда там будут находиться чисто классы, содержащие Guzzle клиенты и удобную обёртку над внешним API. Потом всю бизнес-логику, связанную с этим внешним сервисом можно использовать в классе, который будет находиться в директории Services. И тогда в конструкторе сервиса ты пропишешь что-то вроде: $this->client = new VimeoClient($apiToken); и вызываешь удобные методы, которые ты сам описал. Т.е. Clients - для клиентов к внешним API, а Services / Managers - для бизнес-логики. Я согласен с комментом, где чел сказал, что создавать 10 классов для сложной бизнес-логики не так красиво будет, поэтому используются Services / Managers.
еще провайдера в DI и вообще красота как например в codeigntaer можно написать Services::vimeoClient($apiToken); или и того лучше получять $apiToken на уровне самого провайдера или еще веселее передать return new VimeoClient($apiToken) и вызывать уже Services::vimeoClient(); Ну или еще проще всё в томже провайдере $vimeoClient = new VimeoClient(new Guzzle(), ... ) $vimeoClient->setApiToken($apiToken); return $vimeoClient; Вариантов массов согласен с тобой как обойти более красиво этот момент через сервисы....
проблема экшн классов еще и в том что обычно логику экшена приходится разбивать на несколько функций. а эти функции бывают нужны и в других экшенах. в итоге получаем что экшен класс по большей части свою работу будет выполнять в сервис классах. у меня сервисы тоже обычно это коннекторы к разным апи. а бизнес логика в *Manager классах.
написал длинный коммент про то как надо бы делать, но нажал случайно какую то кнопку и весь текст пропал. в общем, буду краток, неплохо было на вход/выход еще DTO передавать. т.к. в будущем могут появится разные внешние интерефейсы (апи для моб приложения, для клиентов, чат боты и тд).
Где по вашему мнению должна располагаться валидация входных параметров для экшна? (сразу отсеку вариант с FormReaquest т.к. экшн может вызываться откуда угодно, из команды например)
@@LifestarTV Вы правы за исключением того что для этого не нужно использовать пакет. А также того что это компромисс между тем как действительно надо и реальностью. Поэтому очень бы хотелось увидеть ответ CutCode
Вопрос не связанный с видео Как мне в ларавел отсортировать нужное количество товаров к примеру. Есть 100 товаров мне у них есть вип статус и мне нужно отсортировать волшебным образом по вип статусу. Чтоб первые 5 товаров были с вип статусов потом 10 обычных товаров потом 5 с вип статусом и так далее)
Спасибо, интересно! Только я не понял, зачем делать интерфейсы к экшн хендлерам? У меня, например, экшн классов много и все имеют разные аргументы. Или тут имеется ввиду, что для каждого экшн класса надо писать свой интерфейс? Если так, что смысл? Забиндить можно же не только интерфейс, но и сам класс, или я что-то не понимаю)
@@ДенисКуликов-м3о действительно упоминают в примерах кода, а так же на laracast, но конкретных примеров реализации нет. На практике паттерн repository использовать с eloquent не самая лучшая идея. Мы на проекте получили только лишний слой абстракции, теперь убираем все это. Если интересно можете на хабре найти минимум две статьи про то как это можно сделать, почему не стоит, и почему это все же не repository.
Для чего нужна эта привязка контракта к action? ведь зачастую в action реализуется один метод __invoke, в таком случае создание контракта(интерфейса) с одним методом это ведь излишне
Когда условно контракт для какого-нибудь сервиса или фабрики твоей, более логичен и востребован, и там можно можно уже применить эту привязку, и для чего вообще стоит указывать контракт вместо самого сервиса или фабрики? чем это помогает вообще при разработке?
@@coopsprofi8617 в случае написания нового action класса можно будет одном месте в сервис провайдере внести изменения, а не бегать по десятку контроллеров и править в них.
Кране непоследовательное изложение. Ужас. Сначала говорим, что трейты - плохая идея, хотите трейты - пищите в комменты, и тут же как создать трейт. ДЛЯ ЧЕГО ТАКОЕ ЗАПУТЫВАНИЕ? При том реально не ответил на вопрос - куда переносить логику - ушел в треты. Начало видоса тож сумбурное - ну экшены... но хоть бы абзац - для чего они нужны. такое чувство, что делаешь рекламный проморолик для будущих видосов. А как обучающий - этот видос гавно
Спасибо огромное, раньше не понимал чем отличается экшены от сервисов, почему кто то использует одно а кто то другое
Очень большое спасибо з информативное видео и Ваш труд! Один из самых информативных каналов по laravel в ютубе!
Благодарю, стараюсь!
Ох, хулиган =) по консольным командам тоже хотелось бы видео. Видео с тестами очень ждем!
Принял)
Спасибо за видео. Коммент в поддержку!
Видео заставило задуматься. Спасибо.
Какие мысли породило?)
@@CutCodeRu Прежде всего о нахождении баланса между непосредственно выполнением задачи бизнес логики и наведением порядка, через повышение степени абстракции.
Очень полезный и интересный ролик получился! Спасибо! И тоже жду гайд по тестам)))🙂
Спасибо, сам жду)
Очень похоже на porto, только без tasks, тут главное добавить правило что action не может вызывать другой action, дублирующую логику выносить на уровень тасков, иначе можно получить колбекхелл когда action вызывает др. Action, тот следующий и т. Д. Ещё я бы добавил, что action должен содержать бизнес логику и не иметь прямых зависимостей, а такие вещи как хранение, транспорт и отображение нужно выносить в соответствующие слои
Спасибо, очень интересный ролик)
Старался!
Крутой канал, кайфую прям
Приятного просмотра!
Очень благодарен вам!
👌
Спасибо. Интересный материал и очень полезный. И о трейтах было бы интересно.
Принято!
Почитал коменты), где писали что повествование жесть, как по мне в целом все понятно объяснил, или выносим в папку actions, или в services(я так кстати и делаю), мне больше нравится логику в одном классе писать, ну само собой там не 2 тысячи строк в одном классе)) или в трейты, трейты используем только в том случае, когда будем этот трейты где-то ещё переиспользовать
спасибо за мнение!
6:44 Поддерживаю/реквестирую
Информативно, но как по мне в больших проектах где много бизнес логики сложно найти место где можно лаконично использовать экшин класс и чтоб он был красивым и маленьким как на видео,. Писать 10 экшин классов вместо 1-2 классов по 5 методов не самый лучший подход
Нужно варьировать, иногда отличное решение но не панацея
Такой подход хорошо использовать в небольших проектах. Было бы здорово увидеть видео про DDD и Porto. К примеру в Yii 2 Есть возможность скомпоновать логику в модули, а не разбрасывать всё по папкам. Жалко, что в Laravel из коробки такого нет.
Что мешает скомпоновать логику в модули на Laravel?)
@@fredmorrison7513 вот хотелось бы посмотреть как это делается, желательно на русском.
Почему бы не хранить взаимодействие с другими сервисами в директории Clients?
Тогда там будут находиться чисто классы, содержащие Guzzle клиенты и удобную обёртку над внешним API.
Потом всю бизнес-логику, связанную с этим внешним сервисом можно использовать в классе, который будет находиться в директории Services.
И тогда в конструкторе сервиса ты пропишешь что-то вроде: $this->client = new VimeoClient($apiToken); и вызываешь удобные методы, которые ты сам описал.
Т.е. Clients - для клиентов к внешним API, а Services / Managers - для бизнес-логики.
Я согласен с комментом, где чел сказал, что создавать 10 классов для сложной бизнес-логики не так красиво будет, поэтому используются Services / Managers.
еще провайдера в DI и вообще красота как например в codeigntaer можно написать Services::vimeoClient($apiToken); или и того лучше получять $apiToken на уровне самого провайдера или еще веселее передать return new VimeoClient($apiToken) и вызывать уже Services::vimeoClient();
Ну или еще проще всё в томже провайдере
$vimeoClient = new VimeoClient(new Guzzle(), ... )
$vimeoClient->setApiToken($apiToken);
return $vimeoClient;
Вариантов массов согласен с тобой как обойти более красиво этот момент через сервисы....
То что нужно, спасибо!
спасибо за видос ) + за трейты
Принял)
проблема экшн классов еще и в том что обычно логику экшена приходится разбивать на несколько функций. а эти функции бывают нужны и в других экшенах.
в итоге получаем что экшен класс по большей части свою работу будет выполнять в сервис классах.
у меня сервисы тоже обычно это коннекторы к разным апи. а бизнес логика в *Manager классах.
В экшен классе должен быть только один метод, в твоём случае он слишком жирный и ты должен использовать экшен а не метод в другом экшене
написал длинный коммент про то как надо бы делать, но нажал случайно какую то кнопку и весь текст пропал.
в общем, буду краток, неплохо было на вход/выход еще DTO передавать. т.к. в будущем могут появится разные внешние интерефейсы (апи для моб приложения, для клиентов, чат боты и тд).
Согласен но урок немного не об этом, слишком бы раздулся
@@CutCodeRu а можно урок по DTO (когда зачем как и почему)?
@@dimagudkov2697 есть такой, ищите на канале
8:34 assertEquals должен быть не $user, a $user->email
Да, конечно! Это набросок, не заметил
Это phpstorm? Можно ссылку на тему?
Использую DTO для передачи данных, вместо непонятного array $data
Подскажите, что за тема для phpstorm используется?
Nord
Где по вашему мнению должна располагаться валидация входных параметров для экшна? (сразу отсеку вариант с FormReaquest т.к. экшн может вызываться откуда угодно, из команды например)
Можно использовать пакет spatie/laravel-data и передавать в экшн объект Data (создавая его методом Data::validate)
@@LifestarTV Вы правы за исключением того что для этого не нужно использовать пакет. А также того что это компромисс между тем как действительно надо и реальностью. Поэтому очень бы хотелось увидеть ответ CutCode
Влидация должна быть "с наружи". По умолчанию для всех экшенов считаем что пришли корректные данные
Вне экшена
@@НиколайШи-с9о Почему? не поделитесь источником?
Вопрос не связанный с видео
Как мне в ларавел отсортировать нужное количество товаров к примеру.
Есть 100 товаров мне у них есть вип статус и мне нужно отсортировать волшебным образом по вип статусу. Чтоб первые 5 товаров были с вип статусов потом 10 обычных товаров потом 5 с вип статусом и так далее)
Что мешает сделать три отдельных запроса к БД со своими сортировками ?
если хотите быстро получать помощь - пишите сюда - t.me/laravel_chat
Без нормальной модульности из коробки, это все равно каша. Представляю какой кайф заходить в папку Actions и видеть там пару сотен файлов, красота.
чтобы разгрузить логику в контроллерах , надо загрузить приложение абстракциями )
♥️👍
Спасибо, интересно! Только я не понял, зачем делать интерфейсы к экшн хендлерам? У меня, например, экшн классов много и все имеют разные аргументы.
Или тут имеется ввиду, что для каждого экшн класса надо писать свой интерфейс? Если так, что смысл? Забиндить можно же не только интерфейс, но и сам класс, или я что-то не понимаю)
Только для там где есть вероятность изменения реализации, для дальнейшей гибкости
В итоге, если используешь экшен классы, в контроллерах ветвления вообще не бывает?
Все бывает, зависит от реализации
Repositories не популярны?
В laravel нет
@@CutCodeRu хотя даже в документации они упоминаются
@@pryanik150 наверно путаете с resources
@@CutCodeRu раздела конечно нет про них
Но в примерах кода упоминаются
@@ДенисКуликов-м3о действительно упоминают в примерах кода, а так же на laracast, но конкретных примеров реализации нет. На практике паттерн repository использовать с eloquent не самая лучшая идея. Мы на проекте получили только лишний слой абстракции, теперь убираем все это. Если интересно можете на хабре найти минимум две статьи про то как это можно сделать, почему не стоит, и почему это все же не repository.
Зачем придумывать велосипед ? ( ViewModel ) Используйте доктрину
Для чего нужна эта привязка контракта к action? ведь зачастую в action реализуется один метод __invoke, в таком случае создание контракта(интерфейса) с одним методом это ведь излишне
Когда условно контракт для какого-нибудь сервиса или фабрики твоей, более логичен и востребован, и там можно можно уже применить эту привязку, и для чего вообще стоит указывать контракт вместо самого сервиса или фабрики? чем это помогает вообще при разработке?
Гибкостью и подстановкой
@@CutCodeRu Спасибо за ответ! А зачем эта гибкость в actions ? которые реализуют один метод по сути invoke
@@coopsprofi8617 в случае написания нового action класса можно будет одном месте в сервис провайдере внести изменения, а не бегать по десятку контроллеров и править в них.
Не слово про repository хотя документация ларавел продвигает его в своих примерах.
Что за тема php storm ?
Nord
Кране непоследовательное изложение. Ужас. Сначала говорим, что трейты - плохая идея, хотите трейты - пищите в комменты, и тут же как создать трейт. ДЛЯ ЧЕГО ТАКОЕ ЗАПУТЫВАНИЕ? При том реально не ответил на вопрос - куда переносить логику - ушел в треты. Начало видоса тож сумбурное - ну экшены... но хоть бы абзац - для чего они нужны. такое чувство, что делаешь рекламный проморолик для будущих видосов. А как обучающий - этот видос гавно
повествование у тебя просто жесть, учись как то развивать мысль или делать заставки в нужных местах на 4-й минуте подумал что ты уже ролик закончил.