Часто нужно создать какой-то объект некой сущности в системе.
Например, сущность Заказ, эта сущность содержит в себе несколько других сущностей: Товары и Покупатель.
Это не совсем классическая сущность, которая является записью таблиц из бд, а своя, которая может содержать свои свойства и методы (может это как-то называется по другому).
Как мне ранее объясняли здесь, нужно создавать три сущности: Заказ, Покупатель и Товар.
Далее у каждой сущности должен быть некий репозиторий, через который мы можем получать эти сущности через методы, getById, findByCritical и т.д.
Что делать, если не хочется для каждой сущности плодить репозитории ? т.к. по сути для каждой сущности нужен только 1 метод: getById.
Ранее я этот делал так: прямо в конструктор сущности передавал ID, а в конструкторе через API получал данные сущности и заполнял свойства. - это решение никому не понравилось и все критиковали на этом форуме.
Вопрос, какие тогда еще варианты есть ? можно пожалуйста примеры ?
Может в каждой сущности создавать метод-фабрику, createById ? которая будет получать данные сущности, заполнять свойства и делать return self ? или как правильно организовать это, чтобы не плодить лишние сузности.
UPD
Мне не нравится вариант с репозиториями, т.к.
1. у каждого репозитория у меня будет только 1 метод. - getById
2. у каждой сущности у меня по 20 свойств, т.е. из репозитория в конструктор сущности нужно передавать 20 параметров - выглядит чудовищно, решение: создать DTO и передавать в конструктор
3. получается, еще одно доп. сущность - DTO
В итоге, для каждой сущности, нужно:
сама сущность + его интерфейс, репозиторий, DTO сущности + классы исключения для репозитория EntityNotFoundException для getById
выглядит очень громоздно, для простой сущности, которая является лишь обердкой над существующим API, которай просто должен получить данные по API и создать нексколько методов
То что ты перечислил это Модели данных, обычно они наследуются от какой то общей модели в которой в свою очередь уже реализованы определенные методы, такие как getById и прочие.
Далее у каждой сущности должен быть некий репозиторий
- как правило это база данных с таблицами по сущностям, иначе как ты будешь заказы например хранить?
Не совсем ясен вопрос: причём тут репозиторий и фабрика сущности
Репозитории ВОССТАНАВЛИВАЮТ объект сущности из персистенся-слоя, а создаёте вы объект в др кейсе
Кроме того репозитории в той же Доктрине как правило наследуют EntityRepository, который избавляет вас от создания репозиториев для примитивных ситуаций
Или если не наследует (его нет), то через EntityManager вы можете достать EntityRepo для вашей сущности
на самом деле выглядит громоздко, но в этом есть ряд приимуществ.
1. вы не зависите от слоя хранения, получения
2. легко накатить тесты
попробуйте организовать вашу логику и работу приложения не концентрируясь на внешнем апи.
1. создайте сущности+интерфейсы+исключения
2. создайте тестовый репозитрий реализующий метод получения но с хранением объектов прямо в репо.
3. реализуйите логику работы с репозиториями и сущностями
4. покройте код тестами используя тестовый репо, проверьте работу приложения
5. реализуйте репозиторий работающий с внешним апи, переключите работу приложения на него.
из приемуществ: тестируемый код , маштабируемость в будущем.
