My<cod/>.net
WCF-объекты домена и IExtensibleDataObject
Типичный сценарий. Мы используем старой школы XML internally web-сервисов для обмена данными между серверами фермы и нескольких распределенных и локальных клиентов. Никакие третьи лица не участвуют, только наши приложения, используемые нами и нашими клиентами.
В настоящее время мы размышляем о переходе от модели XML WS к модели WCF/object-based и экспериментируем с различными подходами. Один из них включает в себя передачу объектов домена / агрегатов непосредственно по проводу, возможно, вызывая атрибуты DataContract на них.
Используя IExtensibleDataObject и DataContract с помощью свойства Order на DataMembers, мы должны быть в состоянии справиться с простыми проблемами управления версиями свойств (помните, что мы контролируем всех клиентов и можем легко принудительно обновить их).
Я постоянно слышу, что мы должны использовать выделенные объекты передачи данных только для передачи данных ( DTOs ) по проводу.
Почему? Есть ли еще причина для этого? Мы используем одну и ту же модель домена на стороне сервера и на стороне клиента, конечно, предварительно заполняя коллекции и т. д. только в том случае, когда это считается правильным, и свойства коллекции "necessary." используют принцип Service locator и IoC для вызова либо NHibernate-based "service" для прямой выборки данных (на стороне сервера), либо клиента WCF "service" на стороне клиента для связи с фермой серверов WCF .
Итак-почему мы должны использовать DTOs ?
Работая с обоими подходами (объекты общего домена и DTOs), я бы сказал, что большая проблема с объектами общего домена заключается в том, что вы не контролируете всех клиентов, но из моего прошлого опыта я обычно использовал бы DTOs, если бы скорость разработки ИТ не была существенной.
Если есть хоть какой-то шанс, что вы не всегда будете контролировать клиентов, тогда я определенно рекомендую DTOs, потому что как только Вы делитесь своими доменными объектами с чьим-то клиентским приложением, вы начинаете привязывать свои внутренние устройства к чьему-то циклу разработки.
Я также нашел DTOs полезным при работе в версионной среде обслуживания, что позволило нам радикально изменить внутренние компоненты нашего приложения, но по-прежнему принимать вызовы к старым версиям наших интерфейсов обслуживания.
Наконец, если у вас есть много клиентских приложений, возможно, также будет полезно использовать DTOs, поскольку вы будете защищены с помощью легко версируемой службы.
По моему опыту DTOs наиболее полезны для:
- Строго определяя, что будет отправлено по проводу, и имея тип, специально посвященный этому определению.
- Изоляция rest вашего приложения, клиента и сервера от будущих изменений.
- Совместимость с non-.Net системы. DTOs, конечно, не является обязательным требованием, но они облегчают разработку типов "safe".
В вашем сценарии эти конструктивные особенности могут не иметь большого значения. Я использовал WCF как со строгим DTOs, так и с объектами общего домена, и в обоих сценариях это сработало отлично. Единственное, что я заметил, отправляя доменные объекты по проводу, - это то, что я обычно отправлял больше данных (и неожиданными способами), чем мне было нужно. Скорее всего, это было вызвано скорее отсутствием у меня опыта работы с WCF, чем чем-либо еще; но это то, чего вы определенно должны опасаться, если решите пойти этим путем.