Ты не совсем понимаешь что такое политики, поэтому рекомендую начать знакомство с ними с документации.
Почему следует использовать политики вместо сторонних решений? Потому что это стандартный инструмент фреймворка и стоимость разработки и поддержки при этом на порядок ниже.
Ну и один камень в огород overkill решений вроде Entrust - это проблемы с быстродействием (N+1, например), баги и более сложная (часто нечитаемая) итоговая логика. Эти проблемы возникают из-за неумения новичков обращаться с пакетами и из-за непонимания как именно они работают "под капотом". А именно новички, прочитав очередной туториал, начинают использовать этот пакет в каждом своем приложении, даже там, где есть всего…
Данные — это БД в большинстве случаев.
Все, что связано с данными, лучше хранить в моделях. Если есть преобразование данных, тогда Eloquent Resource классы (в 5.5+), либо отедльные классы для преобразования.
Все остальное хранить лучше в классах с бизнес логикой и сервисах, в зависимости от архитектуры. На счет структуры папок, я использую стандартную. Сервис классы в app\Services, модели в app\.
Не встречал обсуждений этого вопроса. Думаю, что лучше в форуме задать этот вопрос.
Спасибо, добавлю именование таблиц для полиморфических отношений.
Пропустил этот момент. Добавил в статью. Спасибо большое.
Учитывая то, что практически все реальные приложения пишутся игнорируя описанное в статье, не такие уж и «истины».
Понимаю, тоже часто с подобным отношением сталкиваюсь. Не все понимают важность использования хороших практик для создания поддерживаемых приложений. Если есть дополнения к практикам в репозитории, буду рад о них услышать. )
Спасибо за идею, если будет время, займусь. А пока, вот такой вот репозиторий есть.
И какая там более сложная нечитаемая логика?
public function handle($request, Closure $next, $roles)
{
if (!is_array($roles)) {
$roles = explode(self::DELIMITER, $roles);
}
if ($this->auth->guest() || !$request->user()->hasRole($roles)) {
abort(403);
}
return $next($request);
}
Тут же все элементарно.