Посмотрел кучу примеров в интернет, по работе с моделями в Laravel. Но так и не смог найти нормального описания, где же все-таки работать с моделями при реализации какого-то процесса. Какую сущность Laravel надо использовать, чтобы инкапсулировать процесс работы с моделью в отдельном классе? Т.е например, есть модель Bascet - корзина товаров, которые выбрал пользователь. Сам процесс работы с корзиной может содержать такие методы как: создать корзину для пользователя, заполнить корзину товарами, отправить корзину на почту пользователя, удалить корзину, пересчитать товары и т.д. и т.п. Вытаскивать работу с моделью корзины в контроллер, на мой взгляд - не правильно, т.к. если модель используется в нескольких контроллерах, то если я поменяю имя метода в модели - ищи по всем контроллерам и меняй имя метода ну как например. добавлять логику работы с корзиной в модель - тоже, ИМХО, как-то не туда. Вообщем, тут https://laravel.su/docs - все более чем в общих понятиях описано. В других публикациях тоже никто не заморачивается или все в контроллере или просто куски кода непонятно где используемые выделил жирным вопрос, чтобы он не потерялся в тексте
Сделайте для себя Actions, к которым будете обращаться из контроллера...Для заполнения корзины в контроллере обращается к одному Actions, для удаления корзины обращаетесь к другому Actions. А сами Actions уже обращаются к нужной модели...
В вашем случае можно использовать один контроллер, в котором будут содержаться методы, для реализации нужных задач. То есть контроллер, это класс который ничего не делает, а лишь указывает другим классам (Actions) что им нужно сделать. Actions классы, содержат в себе бизнес логику. Выполняют добавление, изменение, удаление и т.д. Обращаясь при этом к нужной модели. Models это обычная модель, которая не содержит в себе никакой бизнес логики, а только лишь содержит базовые настройки и связи... Наверное нужно использовать модульную структуру и Eloquent ORM...
То что вы описали еще в первом ответе - понятно, и уточнять нет смысла. Вы написали про Actions. Я попросил Вас уточнить как работать с ними или скинуть ссылку на адекватные примеры использования Actions в проекте. Также поясните, почему именно Actions, а не например ServiceContainer? Ища публикации на эту тему, я нашел, что например тут человек топит за сервис-контейнер, и оперирует что это указанно в документации https://ru.stackoverflow.com/questi...ы-с-базой-данных-и-внешними-api-в-laravel-5-3 т.е. можете аргументировать? или привести ссылку на пример? --- Добавлено --- Т.е. для инкапсуляции бизнес-логики, есть куча вариантов решения. Например я могу: 1. сделать папку в App, BussinesLogic, и разместить там свои классы, которые будут реализовывать логику и манипулировать моделями, как мне хочется. 2. Можно сделать Action (по совету Reken) 3. можно сделать Сервис-контейнер (по другим публикациям) И есть еще 100500 вариатов решения Но что будет правильным с точки зрения фреймворка и программистов, которые потом будут копаться в моем коде ?? Вот в чем вопрос? Если Высчитаете что "правильно" сделать "так-то", то поясните почему? и дайте пруфы на примеры
Ну так есть много разных подходов. Есть DDD (Domain Driven Design), где всё очень строго, есть подход оставить от DDD только сервисный слой, и там дёргать модели (просто создаёшь папку Services, и туда кидаешь свои сервисы), из контроллера дёргаешь. Сейчас модно делать под каждое действие отдельный класс (что вам предложили), а оттуда уже дёргать или модели или сервисы. Само понятие модель растяжимое достаточно. В ларе часто имеют в виду ActiveRecord модель, хотя, в принципе, модель в MVC - это фактически весь слой бизнес логики. Мой принцип - от сложности проекта. Чем сложнее проект, тем критичнее всякие архитектурные промахи. А если у меня Action на 3-4 строчки (а это большинство средних проектов), то я его никуда из контроллера выносить не буду. Вот если там реально гигантский проект, к примеру, на год работы команды хотя бы из 4 человек, то стоит заморочиться и выбрать более сложный подход (тот же DDD, который на маленьком проекте сведёт тебя с ума кучей ненужных действий, и наоборот, на большом проекте пихание Active Record прямо в контроллеры сведёт тебя с ума). Кстати, недавно добрался до Фаулера, "Шаблоны корпоративных приложени", и там, в принципе, ровно это и написано - всё зависит от сложности и размеров проекта.