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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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