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

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

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

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

P.S. Еще момент - если реализовывать по первому формату с 4 моделями, то как сделать единую авторизацию для всех в рамках стандартной аутентификации Ларавела?..
  • Вопрос задан
  • 664 просмотра
Пригласить эксперта
Ответы на вопрос 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
По идее пользователи - отдельно, роли - отдельно.
И один пользователь может иметь несколько ролей, т.е. между пользователями и ролями д.б. таблица связи.
И связи один ко многим.

Итого имеем три таблицы: пользователи, роли, связи.
Ответ написан
dlnsk
@dlnsk
ПК Партнер 01.01 -> ПК Поиск -> IBM PC
Сейчас делаю проект с аналогичной структурой.
Путем проб и нескольких ошибок :) выяснил, что лучше всего делать так:
1. Все поля всех ролей сваливаются в одну таблицу (одинаковые поля не дублируются) и делаются nullable
а) либо в users (получается немного неряшливо);
б) либо в profiles (отношение 1к1 с users), просто чтобы отделить котлеты от мух.
2. В исходниках проверяются НЕ РОЛИ, а разрешения, причем на каждое свойство профиля (учеба, достижения) - свое разрешение.
Это позволит вам в любой момент добавить разрешение, например, на "достижения" в роль клиенту и у него появятся соответствующие элементы форм, вьюх и т.д.

Здесь тоже есть одна тонкость: если роль администратора позволяет ему редактировать чужие профили, то желательно показывать ему только те поля, которые разрешены конкретному пользователю (которого редактирует администратор). Это не является проблемой, если ваш модуль RBAC позволяет навешивать колбэки на проверку разрешений.
Вот модуль с колбэками собственного производства: h-rbac
И статья о нем: Laravel 5. Иерархический RBAC для самых маленьких
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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