Очень сложно эту мысль доводить до людей. Я пользовал доктрину только на запись и она почти нигде не ставила палок в колеса. Начинаешь спрашивать у людей чем она плоха - DQL, кверибилдер и т.д. и т.п.
Это инерция мышления. До меня тоже долго доходило.
Да и ORM из-за такого подхода сильно переусложняются.
Если вспомнить, откуда у всех современных Data Mapper-ов растут ноги - а растут они из Hibernate - изначально Hibernate и позиционировалась как "недоORM", которая предназначена прежде всего для персистенции объектов (что и отразилось в названии).
По большому счету, все, что от ORM надо - это "сериализовать" Aggregate Root в РСУБД и "десериализовать" обратно. А именно в РСУБД - чтобы по тем же данным можно было строить индексы, писать select-ы и строить Read Models, иначе бы можно было тупо в какую-нибудь Монгу все сваливать, или, там, в таблички вида (id serial, data jsonb).
Не знали что это покажется некрасивым, убрали из сравнения. Спасибо за фидбек
О, раз вы уж тут! Спасибо за работу, прежде всего.
Хочу чтобы без аннотаций и без автомиграций. Сущности, которыми оперирует ORM - Aggregate Roots, POJO (то есть, кхм, POPO) со связями: могут быть как вложенные сущности, так и Value Objects, и для них нужен гибкий маппинг (что-то по полям разложить, что-то в jsonb сунуть). На каждый Aggregate Root описываются свои правила маппинга, без всякой магии, без аннотаций. В идеале тупо PHP-кодом. Миграции ручные, Lazy load в пень. PK - нативный постгресовый uuid.
Вижу, что все это явно можно сделать, но документация явно ориентирована на "дефолтный" доктриноподобный подход. Я, конечно, сам разберусь, но если ткнете носом в конкретный код или тесты, было бы прекрасно.
github.com
