WCF - Объекты домена и IExtensibleDataObject

Типичный сценарий. Мы используем веб-службы XML старой школы для связи между фермой серверов и несколькими распределенными и локальными клиентами. Никаких третьих сторон, только наши приложения, используемые нами и нашими клиентами.

В настоящее время мы размышляем о переходе от XML WS к модели, основанной на WCF/объекте, и экспериментируем с различными подходами. Один из них предполагает передачу объектов/агрегатов домена непосредственно по проводнику, возможно, вызывая на них атрибуты DataContract.

Используя IExtensibleDataObject и DataContract, используя свойство Order в DataMembers, мы должны иметь возможность справляться с проблемами с управлением версиями (помните, мы управляем всеми клиентами и можем легко принудительно обновить их).

Я продолжаю слышать, что мы должны использовать специальные проводные объекты передачи данных (DTO) по кабелю.

Почему? Есть ли еще причина для этого? Мы используем ту же модель домена на стороне сервера и на стороне клиента, конечно, предварительно заполняя коллекции и т.д. Только тогда, когда это считается правильным и "необходимым". В свойствах коллекции используются принцип локализации сервисов и IoC для вызова либо "службы" на основе NHibernate, чтобы напрямую получать данные (на стороне сервера), так и клиента службы WCF на стороне клиента, чтобы поговорить с фермой серверов WCF.

Итак - зачем нам использовать DTO?

ОТВЕТЫ

Ответ 1

В моем опыте DTO наиболее полезны для:

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

В вашем сценарии эти функции дизайна могут не иметь большого значения. Я использовал WCF как с строгими DTO, так и с общими объектами домена, и в обоих сценариях он отлично работал. Единственное, что я заметил при отправке объектов домена на провод, было то, что я, как правило, отправлял больше данных (и неожиданным образом), чем мне было нужно. Скорее всего, это связано с отсутствием опыта WCF, чем с чем-либо еще; но это то, о чем вы, безусловно, должны быть осторожны, если вы решите пойти по этому маршруту.

Ответ 2

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

Если у вас есть вероятность, что вы не всегда будете контролировать клиентов, я бы определенно рекомендовал DTO, потому что, как только вы делитесь своими объектами домена с кем-то другим клиентским приложением, вы начинаете связывать свои внутренние с кем-то другим разработчиком цикл.

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

Наконец, если у вас много клиентских приложений, может быть полезно использовать DTO, так как вы затем защищены с помощью легко доступной версии.