(UA) IT/Tech Ukrainians in Canada
-
это да. но суть в том, как это сделать лучше с помощью DDD. кстати апдейт. пообщавшись с коллегой выяснил как оно работать должно. у вас есть энтити - это фактически объект представляющий строку таблицы. все действия с ним производятся в специальных сервисах aggregateRoot/aggregate. запись в бд через пропихивание этого объекта в метод репозитория. работа с зависимостями - храним зависимости этого энтити внутри него самого, доступ к этим объектам через него же. например: у нас есть таблицы User и Rights, User имеет поле Rights, соотношение через rightsId (да, через джоин таблицу лучше, это для примера). Чтобы достучаться до таблицы Rights этого юзера, нужно дернуть репозиторий юзеров и взять этого юзера со всеми его зависимостями. меняем свойства объекта, кидаем в repo.save(User) и метод сам разрулит как сохранить то что мы там наменяли во всех энтити. есть проблема, что имея много внутренних зависимостей, будет потенциально много обновлений. и плохой перформанс при батч обновлениях 100-200-300 строк. мы будем исследовать перформанс, бо нам в целом важнее раскидать бизнес логику чтобы она была понятной, чем экономить пару select/update.
-
замороченные методы с кодом типа того что я скинул пока что будет хранить как есть, конвертируя работу с данными в плоскость ООП больше и унося логику создания строки внутрь конструктора. есть идея юзать команды для сайд эффектов внутри конструктора энтити, бо по принципам DDD энтити не может общаться с бд напрямую.
-
Ти щойно описав деякі фундаментальні принципи ORM 😁 Lazy loading solves the 'too many queries' problem Pivot table не "краще" і не гірше, відносини через id коли one to many, через pivot table коли many to many
-
так никто и не сказал, что это какое то чудо и мир перевернули. фактически, мы active record делаем, только без active + привязываем все к бизнес логике нашего проекта. я больше хотел показать, как имплементация DDD выглядит. ты этого нигде не прочитаешь, все описывают лишь какая это классная идея. А вот такие подводные камни сам решай как разруливать. за лейзи лоадинг. а как это будет работать? сам объект не может обратиться потом за данными к бд. вся информация должна быть сразу передана ему на этапе конструктора.
-
я хз шо там і як можна реалізувати в js (not without looking further anyway) User entity [Many-to-Many] $permissions getPermissions() addPermission(Permission $permission) removePermission(Permission $permission) $user = $this->userRepository->find($id) або ->findOneBy([conditions]) або кастом запит there's no query to the related permissions table until $user->getPermissions() is called When/if that happens, it does SELECT * from user_permission where user_id = ... = lazy loading Є ще extra lazy loading, але мені треба бігти
-
Дякую ;)
-
Вообще можно каждый раз в аэропорту 3к просить - infinity money glitch
-
Як приїжав в Канаду за 3000 доларів, рік тому, чи можу я приїхати знову і отримати гроші?
-
Можу пізніше показати повний приклад якщо цікаво, але це все стандартні штуки
-
Нічого не робить) return $this->permissions Цей конкретний приклад - теж не active record, це doctrine (data mapper orm). Entity просто описує відносини, db queries are handled by EntityManager
-
tsh.io/blog/active-record-vs-data-mapper-patterns-in-php/
