現在、サービスからのステータスや応答を示すメッセージを渡すよりも、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 を含む汎用項目を表示します。
例外情報は中央ログ サービスに記録され、サービスから返されない必要があります。
ご意見? コメント? アイデア? 提案?
私の質問に対するさらなる説明
障害契約に関して私が抱えている問題は、ビジネス ルールの伝達です。
たとえば、誰かがログインしたときにアカウントがロックされている場合、そのことをどのように伝えればよいでしょうか? ログインは明らかに失敗しますが、失敗の理由は「アカウントがロックされています」です。
私もそうです:
A) ブール値を使用し、アカウントがロックされているというメッセージでエラーをスローします。
B) 関連情報を含むAuthenticatedDTOを返す
ベストアンサー1
ただし、.NET で例外をスローするとコストがかなりかかるため、オーバーヘッドが発生します。
オブジェクトを XML にシリアル化およびデシリアル化し、低速ネットワーク経由で送信します。例外をスローすることによるオーバーヘッドは、それに比べれば無視できるほど小さいです。
私は通常、例外を投げることにこだわっています。例外は何かが間違っていたことを明確に伝えてくれるからです。全てWeb サービス ツールキットには、これらを処理する優れた方法があります。
サンプルでは、「アカウントがロックされました」というメッセージとともに UnauthorizedAccessException をスローします。
説明:.NET wcf サービスはデフォルトで例外を FaultContracts に変換しますが、この動作は変更できます。MSDN: コントラクトとサービスにおける障害の指定と処理