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

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

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

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

12 wcf
22.08.2008 21:36:55
1 ОТВЕТ
РЕШЕНИЕ

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

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

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

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

17
22.08.2008 22:14:41