Как использовать NHibernate и DTO с RIA Services

Question

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

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

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

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

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

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

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

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

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

Answer 1

Всякий раз, когда я строю слой доступа поверх ORM, я обычно иду вперед и помещаю любой уникальный ключ для объекта в DTO, чтобы он отслеживался, и, конечно, поддержка по умолчанию (T) в случае дополнение

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

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

Answer 2

Чтобы ответить на ваш вопрос на базовом уровне - вы можете посмотреть на модель презентации. У Deepesh из RIA Services есть хорошее вступительное сообщение в блоге об этом.

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

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

НТН

Динеш