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

Silm

Вступил в наши ряды: 10 декабря 2014

Замечен в последний раз: 3 дня назад

Оставил на форуме: 12 сообщений и 5 тем

Последнее сообщение: 16 февраля 2018

Вы сможете отправить письмо, если войдёте

Комментарии (5)

Silm

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

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

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

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

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

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

на

PHP
$this->modelService->createModel($request->all());

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

Как считаешь?
Или быть может правильнее иметь createModel в самой модели, а уже она будет запускать сервисный класс?

Silm

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

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

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

Вот я всё никак не могу придумать как это должно быть организовано...

Silm

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

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

Silm

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

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

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

Можете посоветовать структуру файлов и директорий проекта? Я по этому поводу нахожусь в большом замешательстве и в основном сваливаю все что отвечает за логику работы с данными в файлы в app\Models\