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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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