Как правильно реализовать отношения между моделями?
Добрый день.
Как вы бы реализовали отношения между моделями? например:
Имеется модель reseller, у нее есть различные связи, один к многим, один к одному и т.д.
В данной модели постоянно появляются все новые и новые связи, к примеру:
Связь со списком продаж, связь с заказами, корзинами, витринами, страницами и т.д. и этот список постоянно растёт.
Такой подход по мне очень удобен, т.к есть центральная модель, которая зависит от авторизованного пользователя и через неё можно получить любые связные данные. (т.к удобное же reseller->getSales(), reseller->getCarts() и т.д)
Но мне не нравится, что такая модель быстро разрастается, и получается какой-то класс БОГ, знающий все и вся, с нарушением всех принципов SOLID.
UPD: пример в вопросе не реальный, а чисто для вопроса придуманный.
reseller выступает в качестве фабрики, который создает нужную более мелку сущность зависящую от ID reseller. Сам этот класс (reseller) можно разбить на более мелки фабрики, типо: создания подсистемы продаж, подсистемы настроек и т.д, а через них уже получать более мелки сущности каждой из подсистем.
Или все это как-то хитро можно завернуть DependencyInjection \ServiceLocator
Или еще как-то?
Как вариант:
1. Создание моделей: заказ, корзина, витрина, страница и т.д. Одна модель может использовать связи с другими таблицами. Как правило одна модель - одна бизнес сущность приложения. Содержит только CRUD функции.
2. Для уменьшением связей между моделями можно создать абстрактный уровень классов который будет реализовывать бизнес логику, взаимодействие между моделями. Например shop->createOrder() получает содержимое корзины и создает заказ.
Так у меня так и есть, одна модель одна сущность (свой набор CRUD операций), просто каждая сущность принадлежит определенному reseller, он и получается абстрактный класс, через, которого и получаются все остальные сущности, принадлежащие ему, т.е его страницы, его заказы и т.д...
Но этот класс быстро разрастается, т.к появляются новые и новые связи, т.е получается необъятная фабрика
Да и пример в вопросе абстрактный, т.е это не магазин, просто на примере его вопрос задала)
Вы не совсем правильно поняли суть вопроса, хотя может это и моя ошибка с его формулирование... Вопрос не о рефакторинге и базовых навыках программирования, а о том, как сделали бы Вы?
Это понятно, что все можно разбить на мелкие сущности, я уже написал об этом, что это и так все разбита на мелкие под классы, просто reseller выступает здесь в качестве фабрики, которая создает нужный класс и инжектит в него зависимость от ID текущего пользователя.
т.е это правильное решение, но так же можно и вручную создавать нужный класс в тот или иной момент, и инжектит в него зависимость от ID.
С разрастанием класса reseller можно бороться дополнительной разбивкой на под классы отвечающие скажем, за подсистему продаж, за подсистему настроек и т.д, а через них уже получить уже более мелки сущности.
А можно все это вынести в отдельный DI или в подобную абстракщину.
