关于WCF：WCF-错误/异常与消息

我们目前正在争论是否通过WCF通道抛出故障是否比传递指示状态或服务响应的消息更好。

故障具有WCF的内置支持，您可以在其中使用内置错误处理程序并做出相应的反应。但是，这会产生开销，因为.NET中的抛出异常可能会非常昂贵。

消息可以包含必要的信息，以确定您的服务调用发生了什么，而不会引发异常。但是，它确实需要几行重复的代码来分析消息并确定遵循其内容的操作。

我们竭尽全力创建了可在我们的服务中使用的通用消息对象，这就是我们想到的：

如果我所有的服务电话都返回了该项目，则我可以始终检查" Success "属性以确定是否一切顺利。然后，我在事件中有一条错误消息字符串，指示出了问题，如果需要，还有一个包含Dto的通用项。

必须将异常信息注销到中央日志记录服务，而不是从该服务传递回。

有什么想法吗？评论？有想法吗？有建议吗？

我的问题有待进一步澄清

我与故障合同有关的一个问题是交流业务规则。

例如，如果有人登录并且其帐户已被锁定，我该如何传达？他们的登录显然失败了，但是由于"帐户锁定"原因而失败。

我也是：

A)使用布尔型，将错误消息锁定在消息帐户上

B)返回带有相关信息的AuthenticatedDTO

This however carries overhead as throwing exceptions in .NET can be quite costly.

您正在将对象序列化和反序列化为XML，并通过一个慢速的网络发送它们。与之相比，抛出异常的开销可以忽略不计。

我通常坚持抛出异常，因为它们清楚地传达出问题，并且所有Web服务工具包都有处理它们的好方法。

在您的示例中，我将抛出UnauthorizedAccessException并显示消息"帐户已锁定"。

说明：默认情况下，.NET wcf服务将异常转换为FaultContracts，但是您可以更改此行为。 MSDN：指定和处理合同和服务中的错误

如果您想像调用任何其他方法一样考虑调用服务，则可能有助于将事情弄清楚。想象一下，如果您调用的每个方法都返回一个状态，而您要检查该方法是对还是错。这样会很乏味。

这是结构化错误处理系统的强项之一，就是您可以将实际逻辑与错误处理分开。您不必继续检查，如果没有引发异常，您就知道它是成功的。

同时，通过返回结果，您将更多的责任放在客户身上。您可能很清楚要检查结果对象中的错误，但是John Doe进来并开始调用您的服务，而忽略了任何错误，因为没有引发异常。这是异常处理的另一大优势，是异常发生并需要注意时，它们可以给我们一个很好的耳光。

我会认真考虑使用FaultContract和FaultException对象来解决此问题。这将使您可以将有意义的错误消息传递回客户端，但仅当出现故障情况时才可以。

不幸的是，我目前正在参加培训课程，因此无法写出完整的答案，但是幸运的是，我正在学习WCF应用程序中的异常管理。我将在今晚发布更多信息。 (对不起，这是一个微不足道的答案)