(UA) IT/Tech Ukrainians in Canada
-
Null coalesce + optional chaining instead of chained ternaries Refactor nested and chained conditions into switch/early returns/guards/etc Вже стане краще
-
это да. но суть в том, как это сделать лучше с помощью 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 выглядит. ты этого нигде не прочитаешь, все описывают лишь какая это классная идея. А вот такие подводные камни сам решай как разруливать. за лейзи лоадинг. а как это будет работать? сам объект не может обратиться потом за данными к бд. вся информация должна быть сразу передана ему на этапе конструктора.
