Может войдёшь?
Черновики Написать статью Профиль

Комментарии Silm

Спасибо, очень полезно.

Я вот пока не понял для чего внедрять пустой экземпляр в класс контроллера.

Обычно внедряются прямо в метод

PHP
public function action(User $firstUserUser $secondUser)
{
    ...
}
VolCh

Тут он исполняет роль некоего подобия репозитория, а не представляет собой конкретного пользователя, предназначен для использования методов типа $user = $this->user->find($request->get('user_id')), $activeUserQuery = $this->users->newQuery()->ofActive() и т. п. По хорошему свойство и параметр $users надо назвать.

В конструктор внедряется репозиторий, а в методы конкретные пользователи.

Что насчет такого подхода:
Модели описывают данные: типы, сеттеры, геттеры, логику изменения состояния объекта, скоупы.
А манипуляции вроде создания новой записи и тп производятся через сервисные классы.

То есть, например, меняем:

PHP
$model $this->model->create($request->all());
$this->modelService->handleUploadedImage($model->id

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

Вот если, скажем, есть таблица images, в ней хранится путь до файла, тайтл, теги, пути до миниатюр и тп. Получается что создание записи в таблице никак не может происходить отдельно от загрузки файла, создания миниатюр и прочих преобразований.

То есть должен быть какой то 1 метод, который отвечает сразу за…

Abraham

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

Спасибо, за ответ.

Пока не понял что надо выносить в сервис и почему не в модель. Вот, в шаге 2, метод handleUploadedImage, он разве не связан с данными?

AlexeyMezenin

Данные — это БД в большинстве случаев.

Замечательная статья, большое спасибо!

Плохо понял второй шаг, точнее то что касается сервисных классов. Можете пояснить концепцию сервисных классов? В чем необходимость выносить логику именно в них и какую именно логику надо выносить в них, а не в модель?

Я обычно стремлюсь помещать всю логику обработки данных в модель, то есть, например запрос на добавление файла: после валидации контроллер дергает метод модели отвечающий за создание новой сущности и передает в нее нужную информацию из реквеста. Модель же уже дергает свои методы, например для ресайза…

VolCh

По хорошему контроллер вообще не должен работать напрямую с моделью, а только с сервисами. Его основная ответственность — адаптировать параметры своего вызова в вызов сервиса, а результат от сервиса в свой результат. Модель должна дергаться уже в сервисе.

Что должно быть в самом сервисе, а что сервисом делегироваться в модель (сущности) вопрос не простой в общем случае, но основной принцип — у модели не должно быть зависимостей, кроме других моделей и чистых функций типа стандартных функций математики или работы со строками/массивами. Прежде всего не должно быть зависимостей от инфраструктуры типа файловой системы, внешних апи, переменных типа $_FILES или оберток для них типа request().

← Назад | Дальше → Движется на Habravel