ORM и DDD

[sda]

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

Много высказываний в том числе от разработчиков баз данных, что ORM теперь не нужны, так как все топовые субд могут хранить JSON структуры и получается, что сохранить агрегат и восстановить из базы не составляет особой сложности, а загружать связи между агрегатами можно и нужно руками. Что думаете, нужен ORM или нет если храним данные как JSON структуры?

[zelenin]

В книге у Вернона прочитал, что не нужно пытаться воссоздавать агрегат из базы с его связями, т.е. в виде агрегата содержащего внутри себя другие агрегаты.

что-то вы не так поняли. вторая часть безусловно верна, но с первой частью не состыкуется.

Вместо этого там говорится, что просто создайте доменный сервис и там загрузите отдельно агрегат, отдельно его связи какие нужны.

о чем речь? о lazy loading в виде dependency resolver?

Много высказываний в том числе от разработчиков баз данных, что ORM теперь не нужны, так как все топовые субд могут хранить JSON структуры и получается, что сохранить агрегат и восстановить из базы не составляет особой сложности, а загружать связи между агрегатами можно и нужно руками

Главная цель ORM - маппинг сущности на БД, а не реализация связей. От способа хранения сущности в БД проблема маппинга не исчезает. Ворочать сотней меговых агрегатов тоже сомнительная затея.

Что думаете, нужен ORM или нет если храним данные как JSON структуры?

в таком виде вопрос не имеет смысла

[ElisDN]

viewtopic.php?f=34&t=36725&p=193847#p193847

[sda]

zelenin, как по ссылке ElisDN. Не пытаться загружать один агрегат внутрь другого. Не использовать lazy loading. Вон Вернон здесь https://vaughnvernon.co/?p=942 пишет, что ORM это устаревшая фича и далее объясняет почему она не нужна. Понятно, что какая-то конвертация данных в объекты должна быть, в статье он использует GSON, но это же не ORM. Раньше пытались сохранить вложенные структуры в плоскую таблицу, а теперь раз базы умеют хранить вложенные структуры, то и ORM не надо. Что не нужны сейчас такие проекты как Doctrine ORM и прочие.

[zelenin]

вернон не про орм пишет, а про принципы, которые они реализуют. все существующие популярные орм прозрачно неработают с json. в статье его код из себя представляет орм с вырезанными связями, только и всего.
плоские таблицы и сейчас существуют используются, см. elasticsearch.
вообще вся разница в подходах это только запрос в хранилище - условно говоря простой селект или селект с джойном - дальше идет то же востанволение объекта из raw данных. весь цикл остается прежним.
не Orm не нужны, а реализуемые ими подходы. melodic видел простую ормку которую я сделал - она из коробки работает с любой структурой хранилища, будь то множество таблиц, или json.

[sda]

Ну хорошо. У меня вопрос. Как проще сконвертировать агрегат в json ? В DDD свойства объекта делают приватными, а доступ через функции геттеры. Через рефлексию http://php.net/manual/en/reflectionclas ... erties.php по приватным полям? Хочется функцию, я ей агрегат, она мне json.

[zelenin]

Ну хорошо. У меня вопрос. Как проще сконвертировать агрегат в json ? В DDD свойства объекта делают приватными, а доступ через функции геттеры. Через рефлексию http://php.net/manual/en/reflectionclas ... erties.php по приватным полям? Хочется функцию, я ей агрегат, она мне json.

ручками. для каждого агрегата своя стратегия.

[sda]

Это слишком муторно и много лишнего кода. Для агрегатов не нужны свои стратегии, они все одинаковые. Любое свойство любого агрегата это примитив, объект или массив объектов. Это можно конвертировать в json в автоматическом режиме, как и сделано у Вернона в статье с помощью gson. Руками конвертировать точно не хочу.

[zelenin]

Это слишком муторно и много лишнего кода. Для агрегатов не нужны свои стратегии, они все одинаковые. Любое свойство любого агрегата это примитив, объект или массив объектов. Это можно конвертировать в json в автоматическом режиме, как и сделано у Вернона в статье с помощью gson. Руками конвертировать точно не хочу.

тогда пишите рефлексию - как еще узнать о наличии приватных методов?

[samdark]

Примерно так: https://github.com/samdark/hydrator

[zelenin]

есть еще некоторые методы, отличные от медленной рефлексии, но: а) менее наглядные, б) использующие недокументированные возможности

https://www.reddit.com/r/PHP/comments/5 ... t_can_get/

[zelenin]

но я все же бы маппинг вручную бы делал: а) наглядно б) минимум кода на агрегат (строк 20 +/-) в) избавляет от сайд-эффектов, когда сохраняются все приватные поля, в т.ч. те, которые не должны сохраняться (вспомогательные типа счетчиков или флажков).
Вручную означает либо написание специфического для модели гидратора либо общего гидратора, работающего с описанными в конфиге поля сущности.

[sda]

Sam Dark, маппинг ключей массива на имена свойств не хотелось бы писать. Хочется, чтобы если маппинг не указан, чтобы она по умолчанию брала все свойства объекта приватные/протектные/публичные.

избавляет от сайд-эффектов, когда сохраняются все приватные поля, в т.ч. те, которые не должны сохраняться

Я считаю, что в агрегате не должно быть таких полей. Мы же должны работать внутри объекта с его состоянием. Состояние объекта не должно иметь сайд-эффектов. Состояние объекта должно полностью сохраняться.

[zelenin]

Я считаю, что в агрегате не должно быть таких полей. Мы же должны работать внутри объекта с его состоянием. Состояние объекта не должно иметь сайд-эффектов.

состояние не имеет сайд-эффектов. сайд-эффекты имеет сериализация всего состояния объекта и последующее его восстановление. На самом деле это известная проблема, с которой я например сталкивался по работе: состояние заказа (со всеми элементами заказа итд) сериализуется, на странице редактирования заказа десериализуется, через 10 дней доменная структура меняется, автоматическая десериализация ломается, т.к. атрибуты модели уже не соотносятся один к одному с json'ом, колл-центр плачет.

[samdark]

Да да. Поэтому я и не запиливал автоматику в библиотечке.

[zelenin]

кстати, провел тесты создания простенькой сущности через конструктор и с помощью рефлексии.
Рефлексия медленнее на 5-20%, хотя в целом там миллисекунды, которыми можно пренебречь.
Тем не менее изучив вопрос, я обнаружил , что большая часть времени уходит на создание объекта ReflectionClass для сущности. Т.к. для одной сущности объект ReflectionClass будет создаваться идентичный, то его можно закэшировать. Тем самым мы делаем рефлексию быстрее в 3-5 раз.

Резюмирую: при правильном использовании рефлексия - не только полезно, но и очень быстро. А так как в DDD могут и будут встречаться кейсы, когда восстановление сущностей нежелательно через публичное апи сущности (при внедренных доменных событиях например), то рефлексия, пожалуй, может быть предпочтительным способом восстановления.

[samdark]

О, хорошая идея.

[samdark]

https://github.com/samdark/hydrator/com ... a2afb659cd

[zelenin]

https://github.com/samdark/hydrator/com ... a2afb659cd

ага, еще проверку убрать https://github.com/samdark/hydrator/blo ... or.php#L52
можно по умолчанию ставить accessible - это чуть ускоряет.

[samdark]

Готово. Спасибо за подсказки.