3

サービス間でビジネス ルールをやり取りするためにメッセージと障害の例外を使用する方法について質問を投稿しました。

この例外をネットワーク経由でスローするためにオーバーヘッドが発生するという印象を受けましたが、シリアル化および逆シリアル化されるのは単なるメッセージであることを考えると、それらは実際にはまったく同じものでした。

しかし、これにより、一般的に例外をスローすること、またはより具体的には FaultExceptions をスローすることについて考えるようになりました。

今、私のサービス内で、私が使用する場合

throw new FaultException

「あなたのアカウントはアクティブ化されていません」のような単純なビジネス ルールを伝えるために、これによりどのようなオーバーヘッドが発生しますか? .NET で通常の例外をスローするのと同じオーバーヘッドですか? または、WCF サービスは、フォールト コントラクトを使用してこれらをより効率的に処理しますか。

したがって、私のユーザーの例では、これがサービスメソッドを記述するための最適な/推奨される方法です

オプション a

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ブロックに入れたい人:)

Microsoft : 例外とパフォーマンス、および代替手段

Developer Fusion: パフォーマンス、例

于 2008-09-19T06:50:07.233 に答える
0

これは通常の例外と同様であり、通常の例外と同じラッピング コードを使用して、スタックの巻き戻しを含め、フォールトにマーシャリングします。

例外と同様に、SOAP フォールトはプログラム フローに使用するべきではなく、エラーを示すために使用するべきだと思います。

于 2008-09-19T06:44:19.027 に答える