Интересное решение.samdark писал(а):Готово. Спасибо за подсказки.
Возникает вопрос: а если мы хотим в модели хранить значениея не 1 в 1 с базой? Например в хранить время в DateTime или что то в VO?
Интересное решение.samdark писал(а):Готово. Спасибо за подсказки.
в ddd это обычное дело. Но гидратор - это не часть ddd или orm. Это лишь прикладной инструмент, помогающий присваивать данные. Конвертировать же данные между ddd-моделью и ее отражением в хранилище должен маппер.nootropil писал(а):Интересное решение.samdark писал(а):Готово. Спасибо за подсказки.
Возникает вопрос: а если мы хотим в модели хранить значениея не 1 в 1 с базой? Например в хранить время в DateTime или что то в VO?
DUser не нужен. Доктрина позволяет использовать доменные сущности.nootropil писал(а):А если с помощью ORM (Doctina) реализовывать репозитории? То есть у нас будет, к примеру сущность DUser, отражающая структуру таблицы (и единичную запись) 1 в 1, которая будет использованна для создания сущности User бизнес логики. Выглядит удобно. Хотя и много сущностей, но логика очень проста.
это правда
я именно так сериалайзеры и делаю: реестр маппингов из конфига и единый сервис. JMS избыточен, имхо. И опять же мы выяснили, что сериализация именно сущностей приведет к неконсистентности.anton_z писал(а): ↑2017.01.15, 16:21Что скажете насчет JMSSerializer (http://jmsyst.com/libs/serializer) для этого кейса? Можно создать сервис, который будет использовать JMSSerializer. на каждый класс будет будет свой маппинг в инфраструктурном слое.