Создание объекта домена из нескольких DTO

Это веб-приложение? Загрузите объект клиента из репо, обновите его из DTO, сохраните обратно. Мне это не кажется чем-то вроде лабиринта. :)

ОБНОВЛЕНИЕ: согласно вашим обновлениям (пример A, B, C, D)

Итак, я подумал, что когда вы загружаете объект, он имеет заполненные A, B, C и D. Если DTO № 1 обновляет только B и C, это нормально. A и D не затронуты (что является желаемой ситуацией).

Что репозиторий делает с обновлениями B & C, зависит от него. Например, если вы используете Hibernate / NHibernate, он просто выяснит это и выпустит обновление.

Тот факт, что в DTO № 1 есть только B и C, не означает, что вы должны также обнулить A и D. Просто оставьте их в покое.

Я бы использовал factory для загрузки полного объекта клиента из репозитория после получения DTO. После этого вы можете обновить только те поля, которые были указаны в DTO.

Это также позволяет вам применять оптимистичный параллелизм к вашему клиенту, например, проверяя последнюю обновленную метку времени.

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

1. Гидратация объекта из репозитория с последующим преобразованием его в DTO - пустая трата усилий. Я предполагаю, что ваш DAL передает DTO в ваш репозиторий, который затем преобразует его в полноценный объект сущности. Поэтому преобразование его обратно в DTO кажется расточительным.

2. Наличие нескольких DTO имеет смысл, если у вас есть страница результатов поиска, которая показывает большой объем записей и отображает только часть данных вашей сущности. В этом случае эффективно передать этой странице только те данные, которые ей нужны. Нет смысла передавать DTO, который содержит частичные данные, на страницу CRUD. Просто дайте ему полный DTO или даже полный объект сущности. Если он не использует все данные, ничего страшного.

Итак, основная проблема заключается в том, что я не думаю, что вам следует передавать данные на эти страницы, используя частичные DTO. Если бы вы использовали полный DTO, я бы сделал следующие 3 шага всякий раз, когда выполняется действие сохранения:

1. Вытащить полный DTO из репозитория или базы данных
2. Обновите DTO любыми изменениями, внесенными через форму
3. Сохраните полный DTO обратно в репозиторий или базу данных

Этот метод требует дополнительного обращения к базе данных, но на самом деле это несущественная проблема для формы CRUD.

Если у нас есть понимание, что репозиторий обрабатывает (почти исключительно) очень богатый объектный объект, тогда вы можете просто отобразить множество DTO.

т.е.

dtoUser.MapFrom<In,Out>(Entity)
or
dtoAdmin.MapFrom<In,Out>(Entity)

вы бы сделали обратное, чтобы вернуть информацию о dto сущности и так далее. Таким образом, ваш репозиторий сохраняет только богатые Entity, НЕ многочисленные DTO

entity.Foo = dtoUser.Foo
or
entity.Bar = dtoAdmin.Bar

entityRepsotiry.Save(entity) <-- do not pass DTO.

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

Кроме того, вы никогда не должны создавать Entity из DTO ... Единственные два способа когда-либо получить Entity - через Factory (новый) или репозиторий (существующий) соответственно.

Вы где-то упоминаете о хранении Entity, зачем вам это делать? Это работа вашего репозитория. Он решит, где взять Entity (db, cache, e.t.c), нет необходимости хранить его где-то еще.

Надеюсь, что это поможет распределить ответственность в вашем домене, это всегда проблема, и тут и там есть серые зоны, но в целом это типичное использование репозитория, DTO и т. д.