WCF - エラー/例外とメッセージの比較

Question

現在、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を含む一般的な項目を持っています。

例外情報は、中央ロギングサービスにログオフされ、サービスから戻される必要はありません。

思考？コメント？アイデア？提案？

私の質問のいくつかの更なる明確化

私は障害契約に抱えている問題は、ビジネスルールを通信しています。

誰かがログインしてアカウントがロックされている場合、どのように通信するのですか？彼らのログインは明らかに失敗しますが、理由は "Account Locked"の理由で失敗します。

だから私の操作を行います。メッセージアカウントで障害を投げ、

A）はブール値を使用するには、

Bをロック）

Answer 1

この関連情報をAuthenticatedDTOを返すしかし、中に例外をスローするようオーバーヘッド運びます。 NETは非常にコストがかかることがあります。

オブジェクトをXMLにシリアル化して逆シリアル化し、低速ネットワーク経由で送信しています。例外をスローするオーバーヘッドはそれに比べて無視できるものです。

私は通常、何かが間違っていたことを明確に伝えているので、例外を投げることに固執します。すべて webserviceツールキットは、それらを処理する良い方法を持っています。

サンプルでは、​​「アカウントがロックされました」というメッセージとともにUnauthorizedAccessExceptionがスローされます。

説明： .NET wcfサービスは、デフォルトでFaultContractsに例外を変換しますが、この動作を変更できます。MSDN:Specifying and Handling Faults in Contracts and Services

Answer 2

これを回避するために、FaultContractオブジェクトとFaultExceptionオブジェクトを使用することを真剣に検討します。これにより、障害状態が発生した場合にのみ、意味のあるエラーメッセージをクライアントに戻すことができます。

残念ながら、私は現時点でトレーニングコースに入っていますので、完全な回答を書くことはできませんが、運が良ければWCFアプリケーションの例外管理について学んでいます。私は今夜​​、より多くの情報を掲示します。 （申し訳ありませんが、微妙な答えです）

Answer 3

他の方法を呼び出すようにサービスを呼び出すと考えると、物事を見通すことができます。あなたが呼び出したすべてのメソッドがステータスを返すかどうかを想像してください。それが真か偽かをチェックするのはあなた次第です。それはかなり退屈になるでしょう。

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

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

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

これは構造化エラー処理システムの強みの1つです。実際のロジックとエラー処理を分離することができます。チェックを続ける必要はありません。例外がスローされなかった場合、成功したことが分かります。

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

同時に、結果を返すことで、クライアントに多くの責任を負うことになります。あなたは結果オブジェクトのエラーをチェックすることはよく知っているかもしれませんが、John Doeが入ってきて、例外がスローされないので何かが間違っているのを知らずにサービスを呼び出すようになります。これは、例外のもう一つの大きな強みです。何かが間違っていて、世話をする必要があるときに、彼らが私たちに顔を殴ってくれることです。