12

私は、少数の WCF アプリケーションがオブジェクトを「分割」することを選択していることに気付きました。つまり、プロジェクトには、ビジネス ロジックを実行する意味のあるクラス ライブラリに加えて、DataContracts/Members を含む DataObjects アセンブリがある場合があります。

これは不要なレベルの抽象化ですか? DataContract 情報を使用して既存のクラス ライブラリを調べてタグ付けすることに関連する固有の悪はありますか?

また、余談ですが、エラー状態をどのように処理しますか? サービスからスローされた例外 (InvalidOperation、ArgumentException など) は一般的に受け入れられていますか、それとも通常はそのあたりにレベルがありますか?

4

1 に答える 1

17

内部ビジネス オブジェクトをデータ コントラクト/メッセージ コントラクトから分離する主な理由は、アプリの内部変更によって必ずしもサービス コントラクトが変更されないようにするためです。バージョン管理された Web サービス (実装されたインターフェイスの複数のバージョンを持つ) を作成している場合、多くの場合、データ コントラクト/メッセージ コントラクト オブジェクトの複数のバージョンを持つアプリ ビジネス オブジェクトの単一バージョンがあります。

さらに、複雑なエンタープライズ統合の状況では、標準データ形式 (データおよびメッセージ コントラクト) が多くのアプリケーションで共有されていることが多く、これにより、各アプリケーションは標準データ形式をその内部オブジェクト モデルにマップする必要があります。

データ コントラクト/メッセージ コントラクトなどを分離する核心に役立つツールが必要な場合は、Microsoft の Web Services Software Factory http://msdn.microsoft.com/en-us/library/cc487895.aspxをチェックしてください。 WCF 配管を解決するための良いレシピ。

例外に関しては、WCF はすべての例外を自動的に FaultExceptions にラップし、ワイヤ形式のエラーとしてシリアル化します。

シリアル化された障害に追加の詳細を含めるように指定できる、一般的な障害例外をスローすることもできます。Web サービス操作によってスローされるエラーはそのコントラクトの一部であるため、操作宣言でエラーを宣言することをお勧めします。

[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);

AuthenticationFault と AuthorizationFault の両方のタイプは、シリアル化してネットワーク経由で送信する追加の詳細を表し、次のようにスローできます。

throw new FaultException<AuthenticationFault>(new AuthenticationFault());

詳細が必要な場合は、叫んでください。私は長い間このようなものを生きて呼吸してきました;)

于 2008-08-22T22:14:41.550 に答える