Ответ 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());
Если вы хотите получить более подробную информацию, тогда кричите; Я живу и дышу этим материалом так долго, что я почти зарабатываю на жизнь;)