My<cod/>.net
Каким WCF лучшим практикам вы следуете при проектировании объектных моделей?
Я заметил, что несколько WCF приложений выбирают "break" своих объектов отдельно; то есть проект может иметь DataObjects assembly, который содержит DataContracts/Members в дополнение к значимой библиотеке классов, выполняющей бизнес-логику.
Является ли это ненужным уровнем абстракции? Есть ли какое-либо врожденное зло, связанное с прохождением и маркировкой существующих библиотек классов с информацией DataContract?
Кроме того, в качестве отступления, как вы справляетесь с условиями ошибок? Являются ли выброшенные исключения из службы (InvalidOperation, ArgumentException и так далее) общепринятыми или обычно существует уровень вокруг этого?
Основная причина отделения внутренних бизнес-объектов от контрактов данных/контрактов сообщений заключается в том, что вы не хотите, чтобы внутренние изменения в вашем приложении обязательно изменяли контракт на обслуживание. Если вы создаете версионные веб-службы (с более чем 1 версией реализованных интерфейсов), то у вас часто есть одна версия бизнес-объектов приложений с более чем 1 версией объектов контракта данных/контракта сообщений.
Кроме того, в сложных ситуациях интеграции предприятия часто используется канонический формат данных (контракты данных и сообщений), который совместно используется несколькими приложениями, что заставляет каждое приложение сопоставлять канонический формат данных своей внутренней объектной модели.
Если вам нужен инструмент, чтобы помочь с мелким песком разделения контракта данных / контракта сообщений и т.д. затем проверьте Microsoft Web Services Software Factory 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());
Если вы хотите больше подробностей, то кричите; Я живу и дышу этим веществом так долго, что почти зарабатываю этим на жизнь ;)