我们目前正在争论通过 WCF channel 抛出错误与传递指示状态或服务响应的消息是否更好。
故障带有 WCF 的内置支持，您可以使用内置的错误处理程序并做出相应的 react 。然而，这会带来开销，因为在 .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) 使用 bool 值，抛出错误并锁定消息帐户
B) 返回 AuthenticatedDTO 以及相关信息
最佳答案
This however carries overhead as throwing exceptions in .NET can be quite costly.
您将对象序列化和反序列化为 XML，并通过慢速网络发送它们。相比之下，引发异常的开销可以忽略不计。
我通常坚持抛出异常，因为它们清楚地传达了出现问题的信息，并且所有网络服务工具包都有一个很好的方法来处理它们。
在您的示例中，我将抛出 UnauthorizedAccessException 并显示消息“帐户已锁定”。
说明:默认情况下，.NET wcf 服务将异常转换为FaultContracts，但您可以更改此行为。 MSDN:Specifying and Handling Faults in Contracts and Services
关于WCF - 故障/异常与消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/81306/