Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Возник каверзный вопрос по архитектуре.
В SAAS приложении, почти все можно делать в trait класса User, ну или в самом классе, просто trait повышает читаемость, понятно что кроме User никакой другой класс не подключит.
Если брать через отношения то к User относятся несколько классов - все связанное с оплатой и подпискам - его карты, подписки, платежи, так некоторые сервисные вещи, к примеру картинки, файлы юзера итд.
Так вот получается, что можно в контроллерах все время дергать, что то типа $user->subscription->isTrial() $user->card->default $user->mainAvatar() примеры и названия совершенно случайны.. В общем управлять через отношения моделями дочерних юзеру моделей. Ну или запихнуть в сам класс/используемый им трейт, что все эти обращения к дочерним моделям и вызывать типа $user->trialSubscription() $user->defaultCard() $user->mailAvatar().
И все это вместо $subscription->isTrial() $card->default() $avatar->mainJpg(); итд. итп.
Но не противоречит ли все это тому, что класс не должен быть раздут и быть супер-классом? Как с этим бороться. Правильный ли путь более менее сложные фичи связанные с дочерними моделями юзера сгонять в сервисный слой и дергать его все равно через класс/трейт юзера?
Понимаю, что вопрос слишком общий... Интересует подход в целом. Что бы не зайти в тупик...
Не в сети
Но не противоречит ли все это тому, что класс не должен быть раздут и быть супер-классом? Как с этим бороться.
Ты используешь Eloquent, это нормально
а проблему твою не понял.
ты пишешь
$user->subscription->isTrial()
а так
$subscription->isTrial()
уже нельзя?
Не в сети
а проблему твою не понял.ты пишешь$user->subscription->isTrial()а так$subscription->isTrial()
Конечно будет работать и так и сяк. Я скорее о том, что везде будет достаточно $user->subscription->isTrial() в контроллерах.. Так как везде есть юзер...
В общем я понял, что подход верный...
Не в сети
Страницы 1