Всем здравствуйте. Помогите разобраться. Пытаюсь использовать сервис классы. Но в

гугле попадаются только статьи, где в один сервис класс пихают все методы, например create и update. И называют класс ArtickeService (как в лучших практиках рекомендуемых https://github.com/alexeymezenin/laravel-best-practices/blob/master/russian.md#%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0-%D0%B2-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B0%D1%85, подразумевая, что в этом классе будут все методы для работы с моделью Article). При этом вроде промелькивают советы, что один сервис класс должен использоваться для одного действия. И вот дальше. Везде в примерах используется инъекция этого сервис класса в конструкторе контроллера. Опять же, если этот сервис класс универсальный, имеет смысл так делать, а если для каждого действия будет свой класс, наверное плохо для производительности создавать в конструкторе контроллера 10 объектов, когда в методе может 1 или 2 будут использоваться. Или я где-то ошибаюсь? Помогите разобраться.

сервис слой - это не про ларавель, ищи общую литературу по архитектуре приложений. "один сервис класс должен использоваться для одного действия" один класс/метод должен иметь одну ПРИЧИНУ для изменения. SRP https://habr.com/ru/articles/465507/ "а если для каждого действия будет свой класс, наверное плохо для производительности" нет, не будет, а когда будет, тогда и обсудим. "создавать в конструкторе контроллера 10 объектов" в конструкторе контроллера лары никаких сервисов не надо инжектить, а в методах, тогда для каждого запроса и подтянешь нужные зависимости, и быть много их не должно обычно (если их много, штук 20, тогда тоже обсудим) https://laraway.github.io/bad-practices/#constructor-controller "если этот сервис класс универсальный, имеет смысл так делать" вполне нормально иногда оставить логику в контроллере, особенно если её там на 2 строчки и она больше нигде не нужна. особенно если это не крупное приложение.

а то что у тебя по ссылке вообще не читай, там не всё ок. здесь лучше: https://laraway.github.io/bad-practices/ https://laraway.github.io/conventions/

Спасибо. Почитаю

На счёт только для одного действия - давайте перейдём тогда на функции, зачем нам классы? SRP - OK, только я предпочитаю ArticlesCRUDService, ArticleSearchService и т.п.

это абстрактная тема. соблюдение солид это всегда будет граничить с холиваром, для разных примеров. ArticlesCRUDService - ну это не ооп, ты просто сгруппировал функции

А если будет ArticleUpdateAction, то намного лучше стало?

немного да, если честно, уже конкретика

Ну я так пробовал, мне не очень понравилась эта куча классов на одну функцию. И почему бы тогда не использовать простые функции? Классы получаются только ради DI от ларки

да эта тема вообще не про ларку

мы просто так можем дойти до CQRS, но я вообще не к тому, что у тебя плохой сервис, который объединил CRUD функции, может у тебя там в в итоге работает как адаптер или фасад, а я к тому, что сложно вести диалог на тему архитектуры, когда тебе надо сделать пару действий с моделью лары. Твой сервис переиспользуем? он тестируем? какие-то правки в нем НЕ могут поломать то, за что он не отвечает? значит всё хорошо.

я хз, может в этом и нет проблем с точки зрения тру ооп....есть же все таки функторы там.....но как то вот странно для меня выглядит класс, который называется действием...

Action же в основном юзают чтобы одни и те же действия переиспользовать в разных классах