Обычные Entity не обязывают переопределять конструктор и серилизатор для поддержки функционала сохранения доктриной. Хотелось чтобы мои работали похожим с доктриной способом.
Так как наш проект уже завязан с doctrine, можно просто использовать её движок аннотаций doctrine/annotations (не забыть указать пакет в composer.json явно)
Help: https://www.doctrine-project.org/projects/doctrine-annotations/en/1.13/custom.html#custom-annotation-classes
Создаем Аннотации @JsonEntity, @JsonEntity\Field Вешаем листенер на PostLoad например, который для каждого класса под аннотацией заберет список сериализуемых атрибутов, и десериализует их.
Не уверен, что он сможет создать обратные сериализаторы и инъектировать их в аннотированную энтити. А события preSerialize нету. да и postLoad походе lifecycleCallback, а не event.
В общем интересная идея на реализацию, но непростая
Серьёзные проекты стремятся к DDD, а там не используют доктриновские сущности в качестве бизнес-моделей. Соответственно в доктриновской сущности эти данные будут сериализованы, а при трансформации её в бизнес-модель, их десериализуют. При сохранении процесс обратный, сначала модель трансформируется в сущность, при этом справочники сериализуются, затем сущность сохраняется. В этом кейсе возникает другая проблема дублирования, в коде живет и работает бизнес-модель, возникает вопрос, а где в этот в момент хранится сущность? При сохранении модели, нам повторно вызывать getById() инстанцировать сущность, и затем как-то сверять её с бизнес-моделью, чтобы учесть произошедшие изменения? В общем это решение тоже не выглядит как то, что мы хотим использовать.