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

Question

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

Это ненужный уровень абстракции? Есть ли какое-либо врожденное зло, связанное с прохождением и маркировкой существующих библиотек классов информацией DataContract?

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

Answer 1

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

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

Если вам нужен инструмент, помогающий разобраться с мелочами, заключающийся в разделении контракта на данные / контракта на сообщения и т. Д., То обратитесь к фабрике программного обеспечения веб-служб 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());

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