Несколько моделей для User провайдера?

Question

[Игорь]

Проблема следующая - у меня есть стандартная модель пользователя, в ней сосредоточен такой функционал, как роли, ограничения, разные getAttribute, setAttribute и т.д. По мере роста проекта пользователю добавляется разный функционал, разные связи. Например, пользователь может взаимодействовать с книгами, с компаниями и т.д. Весь этот функционал засоряет основную модель App\User. Сначала я решил выносить код для каждого функционала в отдельные трейты, т.е. если это функционал работы с компанией, то все связи и методы для взаимодействия с ними находятся в трейте App\Company\UserCompanyTrait, для книг это App\Library\UserBooksTrait и т.д.. Но мне не очень понравилась эта затея и я решил разнести это по классам, наследуя базовый App\User. Вот тут и появилась основная проблема - для того, чтобы использовать метод получения текущего пользователя Auth::user() необходимо, чтобы класс пользователя был явно указан в файле конфигурации авторизации config/auth.php -- providers.users.model. Собственно, сам вопрос - каким образом можно указать либо несколько моделей для одного и того же провайдера, либо базовую модель пользователей так, чтобы была возможность использовать несколько классов?

Answer 1

[Сергей Протько]

Весь этот функционал засоряет основную модель App\User

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

Сначала я решил выносить код для каждого функционала в отдельные трейты,

Это своего рода самообман поскольку у вас всеравно слишком жирные классы выходят. И выходят они потому что знают слишком много.

Но мне не очень понравилась эта затея и я решил разнести это по классам, наследуя базовый App\User

Наследование таблиц. В этом случае провайдер будет продолжать работать с User а уж инстанс какого подтипа будет выплюнут - это уже детали.

Comments

[Игорь]

Можно поподробнее про наследование таблиц? Не совсем понимаю что это..

[Сергей Протько]

Игорь: https://github.com/Nanigans/single-table-inheritance - вот готовое решение например.

[Игорь]

Сергей Протько: Все заработало, спасибо! Только вот вопрос - мне пришлось добавить одно и то же поле типа модели в таблицу пользователей, этого, как я понимаю, избежать мне не получится?

Answer 2

[dmitriy]

По мере роста проекта пользователю добавляется разный функционал, разные связи. Например, пользователь может взаимодействовать с книгами, с компаниями и т.д.

скорее всего нужно слой абстракции для работы с моделями, для этого обычно подходят сервисы

Comments

[Игорь]

В laravel нельзя зарегистрировать несколько абстрактных наследников. Каким образом я могу сделать так, чтобы Auth::user() видел не только методы App\User, но и App\Company\User и App\Library\User ?

Answer 3

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

Лучше не использовать наследование, создать модели отвечающие только за доменную логику, при надобности можно связать их через связь 1-1.