WCF - 错误/异常与消息

我们目前正在讨论是否最好通过WCF通道抛出故障,而不是传递指示服务状态或响应的消息.

故障来自WCF的内置支持,您可以使用内置的错误处理程序并做出相应的反应.然而,这会带来开销,因为在.NET中抛出异常可能会非常昂贵.

消息可以包含必要的信息,以确定服务调用发生的情况,而不会产生抛出异常的开销.但是,它确实需要几行重复代码来分析消息并确定其内容后面的操作.

我们开始创建一个可以在我们的服务中使用的通用消息对象,这就是我们想出的:

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

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

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

如果我的所有服务调用都返回此项,我可以一直检查"成功"属性以确定是否一切顺利.然后我在事件中有一个错误消息字符串表示出现了问题,如果需要,我还有一个包含Dto的通用项.

必须将异常信息记录到中央记录服务,而不是从服务传回.

思考？评论？想法？建议？

对我的问题进一步澄清

我与错误合同有关的一个问题是沟通业务规则.

比如,如果有人登录,并且他们的帐户被锁定,我该如何沟通呢？他们的登录显然失败了,但由于"帐户锁定"的原因导致登录失败.

我也是:

A)使用boolean,抛出Fault并锁定消息帐户

B)返回AuthenticatedDTO及相关信息

然而,这会带来开销,因为在.NET中抛出异常可能会非常昂贵.

您将对象序列化和反序列化为XML并通过慢速网络发送它们.抛出异常的开销与此相比是可以忽略不计的.

我通常坚持抛出异常,因为它们清楚地传达了出错的地方,并且所有的 webservice工具包都有一个很好的方法来处理它们.

在您的示例中,我将抛出一个UnauthorizedAccessException并显示消息"Account Locked".

澄清:默认情况下,.NET wcf服务会将异常转换为FaultContracts,但您可以更改此行为.MSDN:指定和处理合同和服务中的错误

如果你考虑像调用任何其他方法一样调用服务,它可能有助于把事情放在眼里.想象一下,如果您调用的每个方法都返回一个状态,那么由您来检查它是真还是假.这会非常繁琐.

result = CallMethod();
if (!result.Success) handleError();

result = CallAnotherMethod();
if (!result.Success) handleError();

result = NotAgain();
if (!result.Success) handleError();

这是结构化错误处理系统的优点之一,您可以将实际逻辑与错误处理分开.您不必继续检查,如果没有抛出异常,您就知道它是成功的.

try 
{
    CallMethod();
    CallAnotherMethod();
    NotAgain();
}
catch (Exception e)
{
    handleError();
}

同时,通过返回结果,您将更多的责任放在客户端上.您可能知道检查结果对象中的错误,但是John Doe进来并且刚开始调用您的服务,忘记了任何错误,因为没有抛出异常.这是另一个例外的巨大优势,即当出现问题并需要处理时,它们会给我们一个很好的打击.