1

私のサービスのOperationContractの主なパラメーターは、Preapprovalと呼ばれるクラスです。Preapprovalクラスには、DataMember属性のパブリックゲッター/セッターがいくつかあります。セッターへの入力を検証するコードがあります。たとえば、パラメーターが空白であるか、ドメインの適切な範囲外である場合、ArgumentExceptionをスローします。

入力が無効な場合、私は通常、ここでArgumentExceptionをスローします。これはWCFの状況であるため、ここでArgumentExceptionではなく事前定義されたFaultExceptionをスローする必要がありますか？他の場所では、一般的な例外をキャッチして、FaultExceptionsとして再スローする可能性があることを理解していますが、このアクティビティは、WCF配管によって自動的に実行される一部の作業で、スタックの上位で発生します。

たとえば、呼び出し元が私のサービスを呼び出すと、シリアライザーはSOAPを逆シリアル化し、オブジェクトのセッターを呼び出そうとし、実際に操作が呼び出される前にArgumentExceptionがスローされます。したがって、DataContractクラスで、FaultExceptionsをすぐにスローするのは良い設計手法ですか？カスタムハンドラーをチャネルディスパッチャーに接続したくありません。

単純にFaultExceptionsを直接スローできることは理解していますが、そのようなことをサービスに限定したいと思います。避けられない場合は、サポートクラスでもできますが、System.ServiceModelなどとあまり密接に結びついていない典型的なコードをできるだけ書きたいと思います。

ありがとう！

4

2 に答える 2

3

FaultExceptionsはDataContractクラスから除外します。これらのクラスは、WCFコンテキストの外部で使用することをお勧めします。

WCF固有のコードが（属性以外に）DataContractsに侵入するのを防ぐ1つのアプローチは、DataContractクラスに例外をスローさせ、サービスレイヤーでEnterpriseLibraryのWCFExceptionShieldingを使用してそれらの例外をフォールトコントラクトにマップすることです。

基本的に、Enterprise LibraryはIErrorHandler、Exceptionsを実装してFaultExceptionsに変換します。私はハンドラーがあなたが望むことを達成する唯一の方法だと思います（例外はあなたのサービスでスローされないので）。良いニュースは、それを機能させるために実際に多くのことをする必要がないということです。

サービスに属性を追加するだけです。

[ServiceContract]
[ExceptionShielding]
public interface IApproval
{
    [OperationContract]
    [FaultContract(typeof(ApplicationServiceFault))]
    [FaultContract(typeof(SystemServiceFault))]
    void PreApprove(Preapproval preapproval);
}

次に、いくつかの構成（スペースを節約するために構成を省略）を追加して、例外をFaultContractにマップします。操作は引き続きFaultContractsを宣言する必要があることに注意してください。

于 2011-03-29T22:40:29.360 に答える
1

クラスPreApprovalは、Webサービスで使用されていることに気付かないようにする必要があります。他のタイプのアプリケーションから呼び出された場合にスローされたであろう例外をスローさせます。

サービスの「トップレベル」は例外をキャッチし、それらを適切なに変換する必要がありますFaultException。

于 2011-03-30T02:31:25.027 に答える