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

故障来自WCF的内置支持，我们可以在其中使用内置错误处理程序并做出相应的反应。但是，这会产生开销，因为.NET中引发异常的代价可能很高。

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

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

public class ReturnItemDTO<T>
{
    [DataMember]
    public bool Success { get; set; }

    [DataMember]
    public string ErrorMessage { get; set; }

    [DataMember]
    public T Item { get; set; }
}

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

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

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

我的问题需要进一步澄清

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

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

我也是：

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

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

解决方案

回答

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

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

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

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

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

回答

我会认真考虑使用FaultContract和FaultException对象来解决此问题。这将使我们能够将有意义的错误消息传递回客户端，但仅在发生故障情况时才行。

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