Я вот пока не понял для чего внедрять пустой экземпляр в класс контроллера.
Обычно внедряются прямо в метод
public function action(User $firstUser, User $secondUser)
{
...
}
Что насчет такого подхода:
Модели описывают данные: типы, сеттеры, геттеры, логику изменения состояния объекта, скоупы.
А манипуляции вроде создания новой записи и тп производятся через сервисные классы.
$model = $this->model->create($request->all());
$this->modelService->handleUploadedImage($model->id…
Я хочу сказать, что обычно при загрузке изображения всё равно надо сделать запись о нем в БД. Путь и имя файла, возможно еще какие то данные об изображении, чтобы потом можно было манипулировать этим.
Вот если, скажем, есть таблица images, в ней хранится путь до файла, тайтл, теги, пути до миниатюр и тп. Получается что создание записи в таблице никак не может происходить отдельно от загрузки файла, создания миниатюр и прочих преобразований.
То есть должен быть какой то 1 метод, который отвечает сразу за…
Метод сохранения файла вернет имя файла, если он сохранился без проблем и его надо созранять в базу уже. Если модель не сохранилась в базу то файл желательно удалить что бы не засорять место на диске неиспользуемыми файлами. Да и путь незачем в базе хранить. Путь должен быть где то в конфиге, в базе только имя файла.
Пока не понял что надо выносить в сервис и почему не в модель. Вот, в шаге 2, метод handleUploadedImage, он разве не связан с данными?
Замечательная статья, большое спасибо!
Плохо понял второй шаг, точнее то что касается сервисных классов. Можете пояснить концепцию сервисных классов? В чем необходимость выносить логику именно в них и какую именно логику надо выносить в них, а не в модель?
Я обычно стремлюсь помещать всю логику обработки данных в модель, то есть, например запрос на добавление файла: после валидации контроллер дергает метод модели отвечающий за создание новой сущности и передает в нее нужную информацию из реквеста. Модель же уже дергает свои методы, например для ресайза…
По хорошему контроллер вообще не должен работать напрямую с моделью, а только с сервисами. Его основная ответственность — адаптировать параметры своего вызова в вызов сервиса, а результат от сервиса в свой результат. Модель должна дергаться уже в сервисе.
Что должно быть в самом сервисе, а что сервисом делегироваться в модель (сущности) вопрос не простой в общем случае, но основной принцип — у модели не должно быть зависимостей, кроме других моделей и чистых функций типа стандартных функций математики или работы со строками/массивами. Прежде всего не должно быть зависимостей от инфраструктуры типа файловой системы, внешних апи, переменных типа $_FILES или оберток для них типа request().
← Назад | Дальше → Движется на Habravel
Тут он исполняет роль некоего подобия репозитория, а не представляет собой конкретного пользователя, предназначен для использования методов типа $user = $this->user->find($request->get('user_id')), $activeUserQuery = $this->users->newQuery()->ofActive() и т. п. По хорошему свойство и параметр $users надо назвать.
В конструктор внедряется репозиторий, а в методы конкретные пользователи.