Очень похоже на porto, только без tasks, тут главное добавить правило что action не может вызывать другой action, дублирующую логику выносить на уровень тасков, иначе можно получить колбекхелл когда action вызывает др. Action, тот следующий и т. Д. Ещё я бы добавил, что action должен содержать бизнес логику и не иметь прямых зависимостей, а такие вещи как хранение, транспорт и отображение нужно выносить в соответствующие слои
@@CutCodeRu Прежде всего о нахождении баланса между непосредственно выполнением задачи бизнес логики и наведением порядка, через повышение степени абстракции.
Информативно, но как по мне в больших проектах где много бизнес логики сложно найти место где можно лаконично использовать экшин класс и чтоб он был красивым и маленьким как на видео,. Писать 10 экшин классов вместо 1-2 классов по 5 методов не самый лучший подход
Почему бы не хранить взаимодействие с другими сервисами в директории 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; Вариантов массов согласен с тобой как обойти более красиво этот момент через сервисы....
Такой подход хорошо использовать в небольших проектах. Было бы здорово увидеть видео про DDD и Porto. К примеру в Yii 2 Есть возможность скомпоновать логику в модули, а не разбрасывать всё по папкам. Жалко, что в Laravel из коробки такого нет.
Почитал коменты), где писали что повествование жесть, как по мне в целом все понятно объяснил, или выносим в папку actions, или в services(я так кстати и делаю), мне больше нравится логику в одном классе писать, ну само собой там не 2 тысячи строк в одном классе)) или в трейты, трейты используем только в том случае, когда будем этот трейты где-то ещё переиспользовать
написал длинный коммент про то как надо бы делать, но нажал случайно какую то кнопку и весь текст пропал. в общем, буду краток, неплохо было на вход/выход еще DTO передавать. т.к. в будущем могут появится разные внешние интерефейсы (апи для моб приложения, для клиентов, чат боты и тд).
проблема экшн классов еще и в том что обычно логику экшена приходится разбивать на несколько функций. а эти функции бывают нужны и в других экшенах. в итоге получаем что экшен класс по большей части свою работу будет выполнять в сервис классах. у меня сервисы тоже обычно это коннекторы к разным апи. а бизнес логика в *Manager классах.
Спасибо, интересно! Только я не понял, зачем делать интерфейсы к экшн хендлерам? У меня, например, экшн классов много и все имеют разные аргументы. Или тут имеется ввиду, что для каждого экшн класса надо писать свой интерфейс? Если так, что смысл? Забиндить можно же не только интерфейс, но и сам класс, или я что-то не понимаю)
Вопрос не связанный с видео Как мне в ларавел отсортировать нужное количество товаров к примеру. Есть 100 товаров мне у них есть вип статус и мне нужно отсортировать волшебным образом по вип статусу. Чтоб первые 5 товаров были с вип статусов потом 10 обычных товаров потом 5 с вип статусом и так далее)
Где по вашему мнению должна располагаться валидация входных параметров для экшна? (сразу отсеку вариант с FormReaquest т.к. экшн может вызываться откуда угодно, из команды например)
@@LifestarTV Вы правы за исключением того что для этого не нужно использовать пакет. А также того что это компромисс между тем как действительно надо и реальностью. Поэтому очень бы хотелось увидеть ответ CutCode
Для чего нужна эта привязка контракта к action? ведь зачастую в action реализуется один метод __invoke, в таком случае создание контракта(интерфейса) с одним методом это ведь излишне
Когда условно контракт для какого-нибудь сервиса или фабрики твоей, более логичен и востребован, и там можно можно уже применить эту привязку, и для чего вообще стоит указывать контракт вместо самого сервиса или фабрики? чем это помогает вообще при разработке?
@@coopsprofi8617 в случае написания нового action класса можно будет одном месте в сервис провайдере внести изменения, а не бегать по десятку контроллеров и править в них.
@@user-eq5rm5nh4h действительно упоминают в примерах кода, а так же на laracast, но конкретных примеров реализации нет. На практике паттерн repository использовать с eloquent не самая лучшая идея. Мы на проекте получили только лишний слой абстракции, теперь убираем все это. Если интересно можете на хабре найти минимум две статьи про то как это можно сделать, почему не стоит, и почему это все же не repository.
Кране непоследовательное изложение. Ужас. Сначала говорим, что трейты - плохая идея, хотите трейты - пищите в комменты, и тут же как создать трейт. ДЛЯ ЧЕГО ТАКОЕ ЗАПУТЫВАНИЕ? При том реально не ответил на вопрос - куда переносить логику - ушел в треты. Начало видоса тож сумбурное - ну экшены... но хоть бы абзац - для чего они нужны. такое чувство, что делаешь рекламный проморолик для будущих видосов. А как обучающий - этот видос гавно
