WCF 错误处理的更好实践答案

【问题标题】：Better Practice for Error handling from WCFWCF 错误处理的更好实践
【发布时间】：2012-01-10 16:59:34
【问题描述】：

我有一个与我的 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 中处理它 - 但是直接调用服务将需要最终用户针对故障进行编码并正确处理它。

【问题讨论】：

什么是“SOA 故障”？您的意思是“SOAP 错误”吗？不想搞笑，因为“SOA”在这里是一个有意义的术语。

标签： wcf web-services exception

【解决方案1】：

通常我最终要做的是拥有一个会引发应用程序特定异常的业务层。如果我想将其公开为 Web 服务，我将在其上放置一个非常薄的层，将这些业务服务公开为 WCF 服务。该层只会将调用传递给业务层并将结果作为 DataContract 或 MessageContract 对象返回。在这个非常薄的 WCF 层中，我将从业务层捕获异常并将它们映射到 SOAP 错误。这允许任何 .Net 应用程序直接使用业务层并捕获异常，以及 .Net 或非 .Net 应用程序使用 Web 服务并捕获 SOAP 错误。

【讨论】：

【解决方案2】：

我通常使用选项 2（soap 故障，WCF FaultContracts）然后我在做一个内部服务，我知道客户端也是 WCF，我可以确保 FaultExceptions 得到正确处理。

当我提供外部/面向客户的服务时，我通常使用选项 1，将我的消息拆分为“标题”和“正文”，并让标题包含错误消息。我发现在告诉其他人如何使用您的 Web 服务时，这更容易理解，并且对于非 WCF 用户来说也更容易实现。

这两种方法都很好，因为任何语言的任何体面的 SOAP 工具都应该处理 SOAP 错误，但你永远不知道......

【讨论】：

【解决方案3】：

如果你正在构建一个安静的 web 服务，你可以使用 http 状态码。无论服务风格如何，WCF 中的错误处理程序都使代码更具可读性，因为它允许方法的单个 try/catch 定义。

这里有一个简单的例子http://bit.ly/sCybDO

【讨论】：

【解决方案4】：

我每次都会使用选项#2。错误是 SOAP 规范的标准化部分，因此任何兼容的框架都应该适当地处理它们。如果客户正在使用没有内置处理的框架，那么他们将不得不编写自定义代码来执行此操作，但无论如何选项＃1都是这种情况，因为他们必须了解您的自定义错误语义。

除非有很好的理由，否则我将始终使用标准化方法 - 它为您提供了最佳的互操作性机会。

【讨论】：