WCF - Доменные объекты и IExtensibleDataObject

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

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

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

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

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

Итак - почему мы должны использовать DTOs?

24.08.2008 20:34:10
2 ОТВЕТА
РЕШЕНИЕ

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

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

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

6
26.08.2008 17:48:12
Да, Акмад, у меня тоже такие мысли. Вероятно, мы подходим к подходу, который немного смешивает это, передавая чистые «сущности», где это уместно, но делая более основанный на командах формат «сообщения» для более чистых вызовов типа бизнес-процесса.
HenningK 20.10.2008 21:30:43

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

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

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

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

7
1.09.2008 22:44:24
Вы правы, конечно. На каком-то этапе мы собираемся привлекать третьих лиц. Но я больше думаю о том, чтобы представить им необходимую функциональность как «суперслой» поверх этих сервисов WCF, и только тогда, используя пользовательские DTO. Адаптер для нашего сервисного уровня WCF, если хотите.
HenningK 20.10.2008 21:31:50