Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Добрый день.
Многие слышали выражение - "толстый, тупой, уродливый контроллер".
Это выражение означает, что кодеры любят запихивать всю логику приложения в контроллеры, практически не используя модель.
Так как же должна выглядеть модель в Laravel, чтобы контроллеры не были тупыми.
Первый вопрос - можно ли в модели писать свои статические методы?
Подобные: User::selectTops(), Post::selectGoods($user_id), ...
То есть методы - в которых идет сложная выборка с джойнами, группировками и т.д.
Многие считают, что такие методы создавать не стоит, как считаете вы?
Изменено grungestranger (01.06.2017 12:10:10)
Не в сети
Можно, но мне больше нравится пользоваться DI и обходиться без статических методов. Простой пример, контроллер:
public function __construct(User $user)
{
$this->user = $user;
}
public function index()
{
return view('users.index', [
'users' => $this->user->paginateAllUsers()
]);
}
Модель:
public function paginateAllUsers()
{
return $this->paginate(config('admin.pagination'));
}
Вообще, контроллеры должны быть тонкими, вся логика должна находиться с моделях, Request классах (валидация), представлениях (многие в контроллерах меняют формат данных), бизнес логике, классах событий и пр.
Также, методы в моделях, бизнес логике и т.д. не должны быть монструозными. В моделях активно используем scopes, accessors и mutators и пр.
Изменено AlexeyMezenin (01.06.2017 12:25:21)
Не в сети
В этом примере по сути из объекта класса модели User (а объект класса модели User - это по сути - один конкретный юзер) мы получаем набор юзеров. Это как-то против человеческой логики.))
Изменено grungestranger (01.06.2017 12:46:38)
Не в сети
Вообще, контроллеры должны быть тонкими, вся логика должна находиться с моделях
справедливости ради, толстые модели – тоже не комильфо. при росте количества кода в моделях надо обдумать варианты – если много хитрых выборок – вынести их все в репозиторий для данной модели. если в модели накапливаются хитрые хелперы для рендера свойств в видах – такое можно вынести в специальный класс-презентер. по-моему где-то есть даже пакет который позволяет презентеры получать сразу на объектах модели и выводить в шаблонах чем-то типа {{ $post->present()->body }} – на мой взгляд довольно выразительный и простой код получается. про репозитории тоже много чего понаписано
Не в сети
Репозитории нужны, когда не работаешь с ORM и не используешь модели. Иначе, репозитории - это лишний слой абстракции в большинстве случаев.
Не в сети
ну почему же. тут скорее вопрос в реализации принципа SRP. формально говоря представление объектов из базы, логика выборок из неё и рендеринг данных в шаблонах – это разные зоны ответственности. то, что они объединены в ларавеле в одну сущность, преследует задачу избежать оверинжиниринга и обеспечить лучшую масштабируемость вниз – до уровня hello world если надо – при минимуме кода. естественно, если проект растёт вверх и модель оказывается перегружена, эти зоны ответственности есть смысл разделить в какой-то момент при очередном рефакторинге
Не в сети
Страницы 1