Каким рекомендациям WCF вы следуете при разработке объектной модели?

Question

Я заметил, что несколько приложений WCF предпочитают "разбивать" свои объекты на части;то есть проект может иметь сборку DataObjects, которая содержит DataContracts / Members в дополнение к значимой библиотеке классов, выполняющей бизнес-логику.

Является ли это ненужным уровнем абстракции?Существует ли какое-либо неотъемлемое зло, связанное с просмотром существующих библиотек классов и пометкой их информацией DataContract?

Кроме того, в качестве отступления, как вы справляетесь с условиями ошибки?Являются ли генерируемые исключения из сервиса (InvalidOperation, ArgumentException и так далее) общепринятыми, или обычно существует какой-то уровень вокруг этого?

Answer 1

Основная причина отделения внутренних бизнес-объектов от контрактов данных / сообщений заключается в том, что вы не хотите, чтобы внутренние изменения в вашем приложении обязательно меняли контракт на обслуживание.Если вы создаете версионные веб-сервисы (с более чем 1 версией реализованных интерфейсов), то у вас часто есть одна версия бизнес-объектов ваших приложений с более чем 1 версией объектов контракта данных / контракта сообщений.

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

Если вам нужен инструмент, который поможет в решении сложных задач по разделению контракта на передачу данных / контракта на передачу сообщений и т.д.затем ознакомьтесь с фабрикой программного обеспечения веб-служб Microsoft http://msdn.microsoft.com/en-us/library/cc487895.aspx в котором есть несколько хороших рецептов для решения проблемы сантехники WCF.

Что касается исключений, WCF автоматически переносит все исключения в FaultExceptions, которые сериализуются как ошибки проводного формата.

Также возможно генерировать общие исключения ошибок, что позволяет вам указать дополнительные сведения, которые должны быть включены в сериализованную ошибку.Поскольку ошибки, вызванные операцией веб-службы, являются частью ее контракта, рекомендуется указывать ошибки в объявлении операции:

[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);

Оба типа AuthenticationFault и AuthorizationFault представляют дополнительные сведения, подлежащие сериализации и отправке по проводной сети, и могут быть переданы следующим образом:

throw new FaultException<AuthenticationFault>(new AuthenticationFault());

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