Я должен отобразить DTO на доменный объект на обеих сторонах клиента и сервера?

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

Подумайте, что такое веб-сервис. Это не просто абстракция над вашим ORM; это контракт . Это общедоступный API для ваших клиентов, как внутренних, так и внешних.

У общедоступного API не должно быть особых причин для изменений. Практически любое изменение API, кроме добавления новых типов и методов, является критическим изменением. Но ваша модель предметной области не будет такой строгой. Вам нужно будет время от времени изменять его, когда вы добавляете новые функции или обнаруживаете недостатки в исходном дизайне. Вы хотите быть в состоянии гарантировать, что изменения вашей внутренней модели не вызовут каскадных изменений через контракт службы.

На самом деле это обычная практика (я не буду оскорблять читателей фразой «передовой опыт») создавать определенные классы Request и Response для каждого сообщения по той же причине; становится намного проще расширить возможности существующих сервисов и методов, не внося в них критических изменений.

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

А иногда даже невозможно отправить вашу модель обратно через API. Это может происходить по многим причинам:

• Циклы в графе объекта. Прекрасно работает в ООП; провальный в сериализации. В конечном итоге вам придется делать болезненный постоянный выбор в отношении того, в каком «направлении» граф должен быть сериализован. С другой стороны, если вы используете DTO, вы можете сериализовать в любом направлении, в каком захотите, что бы ни соответствовало поставленной задаче.

• Попытка использовать определенные типы механизмов наследования через SOAP / REST может быть в лучшем случае путаницей. Сериализатор XML старого стиля по крайней мере поддерживает xs: choice ; DataContract этого не делает, и я не буду спорить по поводу его обоснования, но достаточно сказать, что у вас, вероятно, есть некоторый полиморфизм в вашей многофункциональной модели предметной области, и чертовски невозможно передать это через веб-службу.

• Ленивая / отложенная загрузка, которую вы, вероятно, используете, если используете ORM. Достаточно неудобно следить за тем, чтобы он был сериализован должным образом - например, используя объекты Linq to SQL, WCF даже не запускает ленивый загрузчик, он просто помещает null в это поле, если вы не загрузите его вручную - но проблема еще больше усугубляется с возвращением данных.Что-то столь же простое, как автоматическое свойство List , которое инициализируется в конструкторе - достаточно распространенное в модели предметной области - просто не работает в WCF, потому что оно не вызывает ваш конструктор. Вместо этого вы должны добавить метод инициализатора [OnDeserializing] , и вы действительно не хотите загромождать свою модель предметной области этим мусором.

• Я также только что заметил в скобках замечание о том, что вы используете NHibernate. Учтите, что интерфейсы типа IList вообще не могут быть сериализованы через веб-службу! Если вы используете классы POCO с NHibernate, как это делает большинство из нас, то это просто не сработает, точка.

Также вероятно будет много случаев, когда ваша внутренняя модель предметной области просто не соответствует потребностям клиента, и нет смысла изменять модель предметной области для удовлетворения этих потребностей. В качестве примера возьмем такую ​​простую вещь, как счет. В нем должны отображаться:

• Информация об учетной записи (номер счета, имя и т. Д.)
• Данные, относящиеся к счету-фактуре (номер счета-фактуры, дата, срок оплаты и т. Д.)
• Информация уровня A / R ( предыдущий баланс, просроченные платежи, новый баланс)
• Информация о продукте или услуге для всего, что указано в счете;
• И т. д.

Это, вероятно, прекрасно вписывается в модель предметной области. Но что, если клиент хочет создать отчет, в котором будет отображаться 1200 таких счетов? Какой-то отчет о согласовании?

Это отстой для сериализации. Теперь вы отправляете 1200 счетов-фактур с одними и теми же данными, сериализуемыми снова и снова - те же учетные записи, те же продукты, тот же A / R.Внутренне ваше приложение отслеживает все ссылки; он знает, что Счет-фактура № 35 и Счет-фактура № 45 предназначены для одного и того же клиента и, следовательно, имеют ссылку на Заказчик ; вся эта информация теряется при сериализации, и вы в конечном итоге отправляете невероятное количество избыточных данных.

На самом деле вам нужно отправить специальный отчет, который включает:

• Все учетные записи, включенные в отчет, и их A / R;
• Все продукты, включенные в отчет;
• Все счета, только с идентификаторами продукта и аккаунта.

Вам необходимо выполнить дополнительную «нормализацию» исходящих данных, прежде чем отправлять их клиенту, если вы хотите избежать массивной избыточности. Это сильно способствует подходу DTO; нет смысла иметь такую ​​структуру в вашей модели предметной области, потому что ваша модель предметной области уже по-своему заботится об избыточности.

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