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

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

Ты не совсем понимаешь что такое политики, поэтому рекомендую начать знакомство с ними с документации.

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

Ну и один камень в огород overkill решений вроде Entrust - это проблемы с быстродействием (N+1, например), баги и более сложная (часто нечитаемая) итоговая логика. Эти проблемы возникают из-за неумения новичков обращаться с пакетами и из-за непонимания как именно они работают "под капотом". А именно новички, прочитав очередной туториал, начинают использовать этот пакет в каждом своем приложении, даже там, где есть всего…

Abraham

И какая там более сложная нечитаемая логика?

PHP
    public function handle($requestClosure $next$roles)
    {
        if (!
is_array($roles)) {
            
$roles explode(self::DELIMITER$roles);
        }

        if (
$this->auth->guest() || !$request->user()->hasRole($roles)) {
            
abort(403);
        }

        return 
$next($request);
    }

Тут же все элементарно.

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

Silm

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

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

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

на

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

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

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

Все, что связано с данными, лучше хранить в моделях. Если есть преобразование данных, тогда Eloquent Resource классы (в 5.5+), либо отедльные классы для преобразования.

Все остальное хранить лучше в классах с бизнес логикой и сервисах, в зависимости от архитектуры. На счет структуры папок, я использую стандартную. Сервис классы в app\Services, модели в app\.

Silm

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

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

Не встречал обсуждений этого вопроса. Думаю, что лучше в форуме задать этот вопрос.

shasoft

Задал на форуме вопрос. Ссылку ставлю чтобы если кто заинтересуется знал где искать
https://laravel.ru/forum/viewtopic.php?pid=15500

Спасибо, добавлю именование таблиц для полиморфических отношений.

Пропустил этот момент. Добавил в статью. Спасибо большое.

Учитывая то, что практически все реальные приложения пишутся игнорируя описанное в статье, не такие уж и «истины».

Спасибо, исправил.

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

Спасибо за идею, если будет время, займусь. А пока, вот такой вот репозиторий есть.

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