2011-07-06 19 views
1

WCFサービスを使用しているクライアントで作業しています。様々なケースでは、サービスは単にFaultExceptionを発生させ、所属の障害の原因を通知するメッセージを関連付けます。WCFフォールトの処理

これらのフォールトの中には、私たちのクライアントアプリケーションで処理できるものがありますが、FaultExceptions MessageまたはReasonで文字列マッチングを試してみるだけです。 。

私は、FaultExceptionのFaultCodeを使用して、処理できる特定のタイプのFaultを特定できると考えていましたが、これは純粋に少数のSOAP障害を特定するためのものです。私の解釈が間違っているなら、私を修正してください。

FaultExceptionが発生する可能性があることは知っていますが、フォールトの背後にある理由ごとに新しいタイプを作成する必要があることは非現実的です。

どのようにこの状況に対処しますか。考案された例として。以下の方法を提供するサービスを考えてみましょう。あなたが存在しないIDを持つGetRecordByIdを呼び出す場合

RecordDetails GetRecordById(string id) 

void Add(RecordDetails record) 

void Update(RecordDetailsUpdateRequest rdur) 

は今、上記の例では、あなたが「レコードが見つからない」というメッセージをFaultExceptionを受けます。同様に、すでに存在するレコードに対してAddを呼び出すか、存在しないレコードに対してUpdateを呼び出すと、失敗の理由を詳述するMessage/Reasonを持つFaultExceptionが取得されます。私はレコードが存在するかどうかを知る必要があり、更新するか挿入するかを決定する必要があります。私が言及したように、私は彼らが同じであるかどうかを支配しないので、文字列に単純にマッチすることをためらっています。

FaultExceptionに関連付けられた型(RecordNotFoundExceptionなどの詳細)、またはエラーに関する特定の詳細を定義するFaultExceptionに関連付けられたジェネリック型です。たとえば、メンバCode(失敗の理由の定数または列挙識別子)を持つRecordOperationExcpetionクラス、およびユーザーフレンドリなメッセージです。

少なくともこの方法では、文字列のマッチングに頼ることなくエラー原因を特定できました。

あなたの考えは高く評価されます。

答えて

2

FaultExceptionに関連付けられているタイプ - 上記のことに行きます。 DataContractとして表される任意の数のクラスを作成して、さまざまなフォルトを処理し、それらをWCFサービス操作に割り当てることができます。

[DataContract] 
public class RecordOperationException 
{ 
    private int code; 
    private string message; 

    [DataMember] 
    public int Code 
    { 
     get 
     { 
      return code; 
     } 
     set 
     { 
      code = value; 
     } 
    } 

    [DataMember] 
    public string Message 
    { 
     get 
     { 
      return message; 
     } 
     set 
     { 
      message = value; 
     } 
    } 
} 

その後、FaultExceptionとして、このクラスを割り当てることができます。

[OperationContract] 
[FaultContract(typeof(RecordOperationException))] 
RecordDetails GetRecordById(string id) 

[OperationContract] 
[FaultContract(typeof(RecordOperationException))] 
void Add(RecordDetails record) 

[OperationContract] 
[FaultContract(typeof(RecordOperationException))] 
void Update(RecordDetailsUpdateRequest rdur) 

必要に応じて、あなたは、その後、あなたの方法で、適切なFaultExceptionをスローすることができます。

これにより、文字列を比較する必要がなくなります(IMOなど)。

+0

これは確かに私の腸感じですが、私はより多くの経験豊富な実務家が、(これは私にはまだかなり新しいです)過去に行っているかを調べるためにだけ熱心だ:

良いリソースです。残念ながら、私はサービスで何が行われているかをあまりコントロールできません。しかし、もし私がなぜそれが特別なやり方で行われるべきかといういくつかの良い事例を提供できれば、それはうまくいって私たちのすべての生活を楽にするでしょう。あなたの入力をありがとう:) –

+0

@Mr Moose - 私は専門家ではありませんが、上記のFaultContractsは、私の知る限り、ベストプラクティスです。ここでは、あなたのためのものをさらに詳しく説明するリンクがあります:[契約とサービスにおける障害の指定と処理](http://msdn.microsoft.com/en-us/library/ms733721.aspx)、[WCFでの例外処理フォルト契約](http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)、[Fault Contract](http://www.wcftutorial.net/Fault-Contract.aspx)を参照してください。 – Tim

0

I 常に FaultExceptionsを使用して、コードが示すように、それらをOperationContractの一部として宣言します。

しかし、これ以上はあると思います。

懸念の分離は良いことであり、あなたがサービスでこれを達成できる方法は、IErrorHandlerを実装する作成されたクラスによることです。

これはあなたのクラスで使用することができ、エラー処理をロジックから切り離して、これをよりクリーンな方法で行うことができます。また、コード全体で同じブロックを繰り返す必要がないことも意味します。

これは一般的なFaultExceptionでも使用できます。 http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.ierrorhandler.aspx

関連する問題