Лучшая практика для обработки ошибок из WCF

Question

У меня есть библиотека классов, которая связывается с моей службой WCF.Библиотека классов может быть использована в любом из моих приложений.Мне любопытно, что было бы наилучшей практикой в ​​обработке ошибок.Я подумал о двух сценариях, но хотел получить обратную связь от сообщества.Идея состоит не только в том, чтобы убедиться, что он подходит для .NET-решений, но и в любом другом языке, который не может использовать dll, а скорее в вызове сервиса напрямую через вызов в стиле SOAP.

Опция # 1 Создайте объект результата, который вернется к API вызывающего.Например.

Public abstract BaseResponse
{
  [DataMember]
  Public bool IsSuccess { get; set;}
  [DataMember]
  Public string ErrorMsg { get ;set ;}
 }

 Public GetProductResponse : BaseResponse
 {
    [DataMember]
    Public Product p { get;set;}
 }

Вариант № 2: Сгенерировать сбой SOA и позволить конечному пользователю обработать его так, как он пожелает.Я мог бы справиться с этим в своем API - однако прямой вызов службы потребовал бы от конечного пользователя кодирования против сбоя и его правильной обработки.

Answer 1

Обычно то, что я делаю, это наличие бизнес-уровня, который будет генерировать исключения для приложений.В случае, если я хочу представить это как веб-сервис, я добавлю очень тонкий слой поверх того, который представляет эти бизнес-сервисы как сервисы WCF.Этот уровень будет делать только передачу вызовов на бизнес-уровень и возвращать результаты в виде объектов DataContract или MessageContract.В этом очень тонком слое WCF я поймаю исключения из бизнес-уровня и сопоставлю их с ошибками SOAP.Это позволяет любому приложению .Net напрямую использовать бизнес-уровень и перехватывать исключения, а также приложениям .Net или не .Net использовать веб-сервис и перехватывать ошибки SOAP.

Answer 2

Я бы использовал вариант № 2 каждый раз.Отказы являются стандартизированной частью спецификации SOAP, поэтому любая совместимая среда должна обрабатывать их соответствующим образом.Если клиент использует платформу, которая не имеет встроенной обработки, ему придется написать собственный код, чтобы сделать это, но в любом случае это относится к варианту № 1, поскольку он должен понимать вашу семантику пользовательских ошибок.

Если бы не было действительно веской причины, я бы всегда использовал стандартизированный подход - он дает вам наилучшие шансы на совместимость.

Answer 3

Если вы создаете полноценный веб-сервис, вы можете использовать код состояния http.И независимо от вида службы обработчики ошибок в WCF делают код значительно более читабельным, поскольку он допускает одно определение try / catch для методов.

Вот простой пример http://bit.ly/sCybDO

Answer 4

Я обычно использую Вариант 2 (ошибки мыла, WCF FaultContracts), затем я выполняю внутреннюю службу, где я знаю, что клиент также является WCF, и я могу убедиться, что FaultExceptions обрабатывается правильно.

Когда яЯ делаю внешнюю / ориентированную на клиента услугу, я обычно использую опцию 1, разделяя мое сообщение на «заголовок» и «тело», и заголовок содержит сообщение об ошибке.Я нахожу, что это легче понять другим людям, когда они рассказывают им, как использовать ваш веб-сервис, и проще для пользователей, не являющихся пользователями WCF.

На самом деле оба способа хороши, поскольку любой достойный инструмент SOAP для любого языка долженобрабатывать ошибки SOAP, но вы никогда не знаете ...