Как хранить наследуемые модели Laravel в БД?

Question

[Станислав Почепко]

Здравствуйте сообщество. Подскажите как работать с наследованием моделей на примере (User, Admin) или (User, Person, Organization) где от User наследуются Admin/Person/Organization. Как их хранить в БД? В частности интересуют лаконичные решения в Laravel, но можно и не привязываться.
По идее при обращении к свойству модели Admin, я должен иметь доступ и к свойствам из модели User. Но как они туда будут попадать? В конструкторе придётся делать заполнение их?
Также при сохранении придётся писать обработчик на событие?
Как этот процесс происходит?

Так же интересны решения для примера, что у каждого типа объекта есть разные dashboard но по одной ссылке (example.com/dashboard). Как делать проверку и привязывать соответствующие контроллеры? Либо контроллер делать один, но вызывать parent методы для реализации разных функционалов?

В общем помогите поднять уровень.
ссылки приветствую

Answer 1

[Вячеслав Плиско]

Не надо БД и модели рассматривать как что-то совместное. Это нормальная ситуация, когда несколько моделей ссылаются на одни и те же таблицы и их колонки в зависимости от контекста поведение может быть разным. martinfowler.com/bliki/BoundedContext.html
При этом модели не обязательно должны (но могут) наследоваться друг от друга, лучшим заменять наследование композицией, тоесть у Admin/Person/Organization будет метод который возвращает User. С учётом Eloquent самый простой и топорный способ, это связь 1-1, что-то вроде

Admin/Person/Organization {
      function user() {  return $this->hasOne('User', 'id', 'id'); }
}

Answer 2

[D']

Для чего использовать разные модели?
Для этой цели нужно использовать механизм ролей.
А для механизма ролей можно использовать https://github.com/Zizaco/entrust
Городить отдельные модели под каждую роль нет смысла.

Comments

[Станислав Почепко]

А как быть, если необходимо реализовать аутентификацию для двух типов. Например пользователи и организации. Роли это понятное дело, но, например, у организации должны быть дополнительные методы для обработки данных.
Например в одном из проектов я видел наследование 3х уровней. User, TransactionUser, Borrower, OrganizationBorrower. Но это без фреймверка.

Я так понимаю, что оно того не стоит?

[D']

Станислав Почепко:
"у организации должны быть дополнительные методы для обработки данных"
Т.е? Причем тут модель юзера?

[Станислав Почепко]

D' Normalization: Ну например, если базовая модель для авторизации User. Person - это персона, а Organization - это соответственно организация. И что бы не реализовывать авторизацию для каждого типа, сделать её на базовой.

[D']

Станислав Почепко: я не понимаю причем тут авторизация? Entrust предлагает роли и пермишены, которые и нужно использовать для разделения доступа и прав.
На пальцах покажите что не дает использовать одну модель с ролями?

[Станислав Почепко]

Вы предлагаете использовать Пользователя. А потом от имени пользователя создавать Организацию. Ну и соответственно проверять, является ли этот пользователь организацией или нет и делать определённые действия. А я к тому, что бы Organization модель была отделённой. То есть это как аккаунт в системе. У неё есть свой логин и пароль. И не важно, кому он принадлежит.

[D']

Станислав Почепко: ответьте на вопрос: что отличает пользователя от организации?

[Станислав Почепко]

Это противоположные стороны, которые взаимодействуют между собой. Организация предоставляет услуги, пользователь потребляет/заказывает. На сайте должно быть реализована регистрация для Организации и Пользозователя. Обычный radio input для определения, кто это будет.
И я так понимаю, что мне надо сначала зарегистрировать пользователя в любом случае, а потом если это организация - то ещё и её создать. Но потом как авторизация организации будет проходить? Форма входа одна для всех.

[Антон Натаров]

Станислав Почепко: Вам пытаются объяснить, что Юзеры, Админы, Организации - это все одна модель User. Авторизация для них работает по одинаковому алгоритму. Вы можете и руками авторизировать юзера. при этом достаточно два поля на проверку.

if (Auth::attempt(['email' => $email, 'password' => $password])) {
      // Аутентификация успешна
      return redirect()->intended('dashboard');
    }

То что у вас выбор при регистрации то это другое дело. И тут вы вольны реализовать так как умеете или захотите. Можно в регистрации поставить инпут на выбор, а в валидации или контроллере проверять какой инпут стоит и в соответствии присваивать желаемую роль. Можно вообще сделать две формы и по инпуту через JQuery скрывать одну из них. При этому валидацию строить на основании инпута.

В модели User - чаще всего лежит техническая информация, логин, мыло, токены, время регистраций, изменений, заходов, ip, если нужно живучие сессии тоже в бд и роль. Вся остальная инфа вносится в модель профиля и там она уже может быть какой угодно от организации до админа и поставщиков.

Авторизация происходит по определенным полям(которые вы сами можете выбрать). Логин и пароль или мыло и пароль, иногда еще и телефон пихают - оно у всех User будет. Вот вы когда в свою квартиру входите. У вас есть дверь и ключ? Ваши родные когда приходят домой, дверь открывают как то иначе? Нет, они открывают тоже ключом, хотя их роль отличная от вашей. Роль не имеет никакого значения в авторизации.

А вот при показе контента или профиля. В зависимости от роли будет разное view или будут показаны скрытые поля именно для этой роли.

[D']

Станислав Почепко: не важно какие там формы. Просто регистрируте пользвателя и в зависимости от чекбокса назначайте ему роль.
Затем просто будете проверять $user->isCompany() или $user->hasPermission('...')
Можете отнаследовать от User модели Person\Organisation, если так хочется, но это ничего не датс.

[Станислав Почепко]

Антон Натаров: То есть по сути мне надо будет в каждой роли хранить тип dashboarda (person/organization)?
А правильно ли делать в таком случае полиморфическую связь? $User->accountable() // return Person/Organization.

[Станислав Почепко]

D' Normalization: Спасибо. Примерно понял.