Как лучше всего реализовать подобную архитектуру?

Здравствуйте.
Размышляю о том, как лучше реализовать следующую архитектуру (ранее проекты не имели столько разных ролей)
В качестве фреймворка хочу использовать Laravel.
У нас есть в системе админ, модератор, куратор и клиент.
Модератор тот же админ с меньшим количеством прав
Куратор следит за успехами клиента в обучении.

У клиента свои атрибуты (например, где учился и т.д.), у куратора свои (достижения и прочее, чего нет у клиента)
Само собой возникает вопрос, как лучше архитектурно это реализовать?
Сделать несколько моделей - (Client, Curator, Moderator, Admin) и у каждого своя таблица с данными, само собой при авторизации нужно будет обращаться к разным таблицам с поиском логина и пароля. Но преимущество в том, что атрибуты не перемешаются.
Второй вариант - модель User и уже в зависимости от роли связь 1 к 1 с таблицей, имеющие дополнительные атрибуты.
Фактически, таким образом у нас при запросах будет использоваться 1 модель.

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

P.S. Еще момент - если реализовывать по первому формату с 4 моделями, то как сделать единую авторизацию для всех в рамках стандартной аутентификации Ларавела?..
  • Вопрос задан
  • 604 просмотра
Пригласить эксперта
Ответы на вопрос 4
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Роли - это множества (точнее - "деревья" множеств), содержащие пользователей.

Расписываю подробно на примере:
Есть пользователь User1, у него роль Admin и роль Curator.
Т.е. он имеет в своём личном кабинете 2 пункта меню: Администрирование и Курирование.
Всё что в базе - привязывается только через ID-шник этого пользователя (роли и поля ролей, и т.п.).
Ответ написан
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
емнип в ларавеле уже есть готовый RBAC. Или можно открутить от симфони/зенда.
По теме - естественно никаких дополнительных сущностей корме юзера не нужно, они отличаются только связанным свойством роли.
Ответ написан
LaRN
@LaRN
Senior Developer
По идее пользователи - отдельно, роли - отдельно.
И один пользователь может иметь несколько ролей, т.е. между пользователями и ролями д.б. таблица связи.
И связи один ко многим.

Итого имеем три таблицы: пользователи, роли, связи.
Ответ написан
Различные атрибуты пользователя, куратора и т.п. можно хранить в JSON поле. Поддержка селектов по такому полю в разных БД разная (но она есть), а если эта информация используется только для отображения на каких-то страницах, тогда вообще никаких проблем.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы