3

我发布了一个关于使用消息与故障异常在服务之间传达业务规则的问题。

我的印象是通过网络抛出这个异常会带来开销，但考虑到它只是一个被序列化和反序列化的消息，它们实际上是相同的。

但这让我开始考虑抛出一般的异常或更具体地抛出 FaultExceptions。

现在在我的服务范围内，如果我使用

throw new FaultException

传达一个简单的业务规则，例如“您的帐户尚未激活”，现在这会带来什么开销？它与在 .NET 中引发常规异常的开销相同吗？或者 WCF 服务是否使用故障契约更有效地处理这些问题。

所以在我的用户示例中，这是编写我的服务方法的最佳/首选方式

选项一

public void AuthenticateUser()
{
    throw new FaultException("Your account has not been activated");
}

选项 b

public AutheticateDto AutheticateUser()
{
     return new AutheticateDto() { 
          Success = false,
          Message = "Your account has not been activated"};
}
4

2 回答 2

4

嗯...一般来说，您不应该为预期的条件或您希望定期发生的任何事情抛出异常。它们比普通方法慢得多。例如，如果您希望文件打开失败，请不要向调用者抛出该异常，将失败代码传回，或提供“CanOpenFile”方法来进行测试。

确实，消息文本本身并不多，但是会抛出并处理一个真正的异常（可能由于 IIS 成本更高），然后在反序列化故障时再次在客户端上抛出真正的异常。所以，双杀。

老实说，如果通话量很少，那么您可能不会受到任何明显的打击，但无论如何也不是一个好主意。谁想把业务逻辑放在一个 catch 块中:)

微软：例外和性能，及替代方案

开发者融合：性能，举例

于 2008-09-19T06:50:07.233 回答
0

它就像一个普通异常，并使用与普通异常相同的包装代码来编组为错误，包括展开堆栈。

就像异常一样，在我看来，SOAP 错误不应该用于程序流，而是用于指示错误。

于 2008-09-19T06:44:19.027 回答