Как использовать NHibernate и DTO с услугами RIA

Question

Я использую NHibernate с RIA Services и Silverlight 4. Я создаю DTO для передачи данных через RIA Services, а не для распространения объектов моего домена (в соответствии с Первым законом Распределенного Мартина Фаулера Дизайн объекта: «Не распространяйте свои объекты!»). Объекты DTO сглаживаются до двух слоев из пяти соответствующих слоев в доменном слое.

Вот моя проблема. После внесения изменений в Silverlight 4 службы RIA знают, какие объекты DTO были изменены, но в коде обновления на стороне сервера мне нужно перенести изменения на «реальные» объекты уровня домена, чтобы NHibernate мог применить эти изменения к база данных. Каков наилучший способ сделать это?

Поскольку DTO должны быть легкими, содержащими только информацию, которая необходима на стороне клиента, я, очевидно, должен был бы не захотеть внедрить соответствующие объекты домена внутри DTO.

Вот некоторые из возможностей, которые я рассмотрел:

1) Держите ссылки на объекты домена в объекты DTO. До тех пор, пока только ссылки получают сериализованные и отправленные по проводу не все объекты, на которые ссылаются, то это может быть разумным подходом. Конечно, ссылки не будут действительны на стороне клиента, потому что они указывают на несуществующие места памяти, но в конце поездки они могут использоваться на стороне сервера. (?)

2) То же, что указано выше, но сохранить только ссылку на корень агрегата домена в объекте DTO. Затем используйте обход отношения объекта, чтобы перейти к другим связанным объектам домена.

3) Сохраните идентификаторы объектов домена в DTO и используйте NHibernate с помощью функции «Получить» по идентификатору или «Загрузить» по идентификатору, чтобы получить правильные объекты домена, чтобы обновления могли быть применены.

4) То же, что и выше, но используйте только «Get» или «Load» для совокупного корня, а затем используйте обход для всех связанных объектов.

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

Answer 1

Всякий раз, когда я строю слой доступа поверх ОРМ, я обычно идти вперед и положить все, что уникальный ключ для сущности в DTO , так что это отслеживается и, конечно, поддерживает дефолт (T) в случае добавления.

Затем, когда объект возвращается на сервер, я могу легко выполнить Load, marshall изменить значения из DTO, а затем либо позволить сеансу сохранить его, либо выполнить явное сохранение.

Это будет ваш 3/4.

Answer 2

Чтобы ответить на ваш вопрос на базовом уровне - вы можете посмотреть модель презентации. Deepesh из команды RIA Services имеет хороший introductory blog post.

Кроме того, вы можете использовать идентификатор вместо ссылки (то есть внутреннее, сериализуемое значение вместо ссылки на объект с областью действия домена) и использовать [Ассоциация].

Чтобы ответить на следующий уровень, использование модели презентации по-прежнему связано с работой и дополнительными типами. Это имеет смысл, когда форма модели, которую вы хотите видеть, существенно отличается от формы на сервере (будь то модель богатого домена или только модель на основе DTO).Увеличение количества типов и необходимость сопоставления между ними - это стоимость, которую вы платите за гибкость. Есть более дешевые варианты, которые делают меньше - например, непубличные члены, директива сериализации [Исключить] и т. д., которые позволят вам сформировать модель с кодовым названием и сериализованной моделью. Возможно, стоит их рассмотреть. В конце концов, типы на двух сторонах границы доверия очень сильно отличаются по умолчанию (например, ваши типы на сервере, а не на типы кода на клиенте).

НТН

Динеш