(UA) IT/Tech Ukrainians in Canada

[t302253680]

Это рекорд! Башня российского танка Т-90М «Прорыв» отлетает на метров 200 после детонации. Курахово. 👉Подпишись. Покажи гражданам рф

[t302253680]

Ту зе мун

[t139189834]

Богдан просто не дуже вболіває за Україну 🤷‍♂️

[t896333795]

Ну якщо вірити цьому джерелу то нехай буде 500 ліквідованих

[t139189834]

Інсайдер щось вигадує

[t139189834]

Ніде інформації про 500 немає

[t139189834]

До зустрічі сьогодні о 3ій в Торонто Exhibition Place .Біля пам'ятника Голодомору 100 Princes' Blvd, Toronto, ON M6K 3C3

[t379434605]

Null coalesce + optional chaining instead of chained ternaries Refactor nested and chained conditions into switch/early returns/guards/etc Вже стане краще

[t6925833687]

Пропаганда же.

[t335448128]

У нас роковини голодомору, тому поляки вирішили долучитися 👍

[t335448128]

suspilne.media/886629-pid-cas-udariv-raketami-storm-shadow-u-kurskij-oblasti-rf-zaginuli-piv-tisaci-vijskovih-kndr-ta-oficeri-rf/

[t335448128]

Так, посилання у них всіх одне. Але Вітя казав, що це тільки Інсайдер постив, а воно уже багато де рознесли. Хоча очевидно, що фейк

[t391561584]

это да. но суть в том, как это сделать лучше с помощью DDD. кстати апдейт. пообщавшись с коллегой выяснил как оно работать должно. у вас есть энтити - это фактически объект представляющий строку таблицы. все действия с ним производятся в специальных сервисах aggregateRoot/aggregate. запись в бд через пропихивание этого объекта в метод репозитория. работа с зависимостями - храним зависимости этого энтити внутри него самого, доступ к этим объектам через него же. например: у нас есть таблицы User и Rights, User имеет поле Rights, соотношение через rightsId (да, через джоин таблицу лучше, это для примера). Чтобы достучаться до таблицы Rights этого юзера, нужно дернуть репозиторий юзеров и взять этого юзера со всеми его зависимостями. меняем свойства объекта, кидаем в repo.save(User) и метод сам разрулит как сохранить то что мы там наменяли во всех энтити. есть проблема, что имея много внутренних зависимостей, будет потенциально много обновлений. и плохой перформанс при батч обновлениях 100-200-300 строк. мы будем исследовать перформанс, бо нам в целом важнее раскидать бизнес логику чтобы она была понятной, чем экономить пару select/update.

[t130861475]

Телеграмм канал досье шпиона

[t391561584]

замороченные методы с кодом типа того что я скинул пока что будет хранить как есть, конвертируя работу с данными в плоскость ООП больше и унося логику создания строки внутрь конструктора. есть идея юзать команды для сайд эффектов внутри конструктора энтити, бо по принципам DDD энтити не может общаться с бд напрямую.

[t391561584]

пермишны обычно гораздо сложнее и решаются через мени ту мени.

[t379434605]

Ти щойно описав деякі фундаментальні принципи ORM 😁 Lazy loading solves the 'too many queries' problem Pivot table не "краще" і не гірше, відносини через id коли one to many, через pivot table коли many to many

[t391561584]

так никто и не сказал, что это какое то чудо и мир перевернули. фактически, мы active record делаем, только без active + привязываем все к бизнес логике нашего проекта. я больше хотел показать, как имплементация DDD выглядит. ты этого нигде не прочитаешь, все описывают лишь какая это классная идея. А вот такие подводные камни сам решай как разруливать. за лейзи лоадинг. а как это будет работать? сам объект не может обратиться потом за данными к бд. вся информация должна быть сразу передана ему на этапе конструктора.

[t391561584]

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

[t391561584]

хм. а что делает getPermissions()? мы не можем изнутри энтити User сделать запрос к бд.