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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

WCF错误处理的更好实践

4 个答案: