Отдельная папка в Controllers для каждой роли?

Question

[Maria_Gavrilova]

У меня в проекте есть роли Admin, Owner, Client, User... В административном интерфейсе Admin и Owner совсем чуть-чуть отличаются (но отличия всё же есть). Нормально ли для каждой роли делать отдельную папку в Controllers и почти дублировать все контроллеры, чуть их модифицируя? Также получается и роуты дублируются... и виды. Посоветуйте пожалуйста организовать структуры. Есть просто мысль, что я много кода дублирую, нормально ли это? Для ролей и разрешений использую "laravel spatie permission".

Comments

[Евгений Ромашкан]

Делить проект по фичам/контекстам на папки со своими контроллерами моделями и роутами - нормально.
Делить проект по тому как информация на страничке выводиться или по ролям - не нормально.

Answer 1

[Евгений Вольф]

Нормально ли для каждой роли делать отдельную папку в Controllers и почти дублировать все контроллеры, чуть их модифицируя?

Нет. Если даже отбросить все прочие "но", представьте, чего Вам будет стоить ввести новую роль в систему?! Это же будет полный ахтунг!

Также получается и роуты дублируются... и виды.

Тем более.

Есть просто мысль, что я много кода дублирую, нормально ли это?

Нет, не нормально. Честно говоря, я не понимаю, как Вы смогли изучить Laravel, при этом обойдя вниманием один из основополагающих принципов разработки DRY.

Для ролей и разрешений использую "laravel spatie permission".

Честно говоря, не знаю что это, но если текущий модуль обслуживания прав/привилегий/ролей/управления доступом (и т.п.) - Вас чем-то не устраивает или заставляет(?) Вас нарушать основополагающие принципы разработки - нужно просто найти другой, более подходящий под Ваши конкретные задачи.

Comments

[Игорь Воротнёв]

По ссылке на packagist упомянутый автором spatie/laravel-permission второй в списке (а по количеству загрузок - первый). Это одна из наиболее популярных либ, и она качественная и адекватная. Чуть более чем полностью подходящая. Тут проблема в авторе, а не в либе.

[Maria_Gavrilova]

Если бы я не слышала про этот основополагающий принцип разработки DRY, то не задавалась бы такими вопросами, а просто продолжала бы дублировать код) А так как я в курсе, то и спрашиваю совета и хотела увидеть примеры как опытные коллеги структурируют такое)

[vism]

Maria_Gavrilova, А просто логика? если надо что-то изменить, придется лезть в 5 одинаковых файлов и менять каждый индивидуально?

[Евгений Вольф]

Maria_Gavrilova, совет:
1. Перестать дублировать код
2. Описывать логику прав доступа либо в специально отведённых для этого классах, либо прямо в контроллерах (что в целом не очень красиво, но в отдельных случаях допустимо)

P.S. Мы обычно даже для контроллеров пишем либо базовый класс, либо трейты. К слову, описать общую логику/механику доступа можно прямо в них.

Answer 2

[jazzus]

Дублировать код ненормально. Попытка провести рефакторинг дублирующего кода, когда идеи могут меняться на ходу, а исправлять в 10 файлах - вас в этом убедит. По поводу проверки доступа в Laravel уже давно все придумано. Добавить к этому связи между таблицами roles, perms и users (многие ко многим), добавить в таблицу роли и разрешения и можно использовать без модулей. И даже здесь проверки делать не по ролям, а по доступу (таблица perms) т.к. доступы у ролей могут пересекаться. Готовых описаний как точно сделать в Интернете полно. Там элементарно. Можно еще добавить булеан поле active к user_role, чтобы можно было быстро деактивировать роль пользователя (у пользователя может быть несколько ролей) с сохранением истории для мгновенного восстановления. Это можно юзать при модерации юзеров с минимумом кода и без ведения логов (получаешь inactive roles пользователя и делаешь active true)

Answer 3

[Дмитрий]

Вам нужно понять принцип использования ролей и разрешений. Возможно вам поможет эта статья:
Laravel 5. Иерархический RBAC для самых маленьких

Answer 4

[Sanes]

Я у себя так и сделал. Разложил вьюхи и контроллеры по разным директориям.
Только у меня по факту 2 самостоятельных приложения, admin и user.
Т.е. не роли, а приложения разделил. Возможно не ваш случай.

Answer 5

[Alex Wells]

Нормально, если между порталами значительно различие. Более чем нормально. Но лучше всего, если разделение будет только на фронтенде, с шереными компонентами где нужно, а на бэкэнде - нормально спроектированный Rest, без разделения на роли в урлах.