6

WCF サービスを参照する dll を作成しています。dll はサービスのゲートウェイとして機能しており、すべての呼び出しはそれを通過します。おそらく、同時呼び出しが存在する可能性があります。

サービスを参照しましたが、ラッパー関数を正しく記述する方法を決定できません。

この機能の例やベスト プラクティスはありますか。

4

2 に答える 2

5

Web サービス インターフェイスに一致するラッパーを作成します。公開されているすべてのオブジェクトをラップすることもお勧めします。基本的にプロキシを作成します。この種のことに本当に役立つと思うのは、API に一致するインターフェイスを作成して実装することです。これにより、WCF 呼び出しに関連するオーバーヘッド (または潜在的なコスト) なしで、テスト用の DLL のダミー バージョンを作成できます。また、将来、WCF 呼び出しを代替プロバイダーに置き換える必要がある場合にも、はるかに簡単になります。

例として、支払いを処理するための外部プロバイダーへの WCF サービスがあると仮定します。このようなもの：

void ProcessPayment(float amount);

これをコードに簡単にフックできます。問題は、インターフェイスを単純に変更すると、コードが参照されるすべての場所で変更を行わなければならなくなることです。インターフェイスがほとんど同じであっても、プロバイダを別のものに変更した場合も同様のことが必要になります。シンプルなインターフェースのようなものを追加します:

interface IPaymentProvider
{
    void ProcessPayment(float amount);
}

コードを WCF サービスから完全に分離します。次のようなクラスを簡単に構築できます。

class PaymentProviderAWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call the WCF service
    }
}

ファクトリまたは Spring.NET のような依存性注入フレームワークを使用して動的にロードできること。プロバイダー B への変更は、新しいラッパーを作成するのと同じくらい簡単です。

class PaymentProviderBWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call provider B's Native DLL
    }
}

コードをプロバイダー A からプロバイダー B に切り替えるのは、構成設定を変更するのと同じくらい簡単です。

ライブラリをコードに直接コンパイルしたとしても、新しいライブラリを使用するように構築ロジックを変更するだけで済みます。アプリケーションの残りの部分はまったく変更されません。単純な再コンパイルです。

于 2012-04-30T12:09:53.870 に答える
2

Graymatter の回答に応えて、同じ呼び出しを公開してから呼び出しを実際のサービスに転送するサービス ラッパーを呼び出すことと、個々の 1 対 1 のマッピングを想定してサービスを呼び出すことの違いがわかりません。呼び出し、トランスポート バインディングに変更はありません。

最初にラッパーを作成する唯一の理由は、何らかの方法で公開されたインターフェイスがそれ自体では要件を満たしていないためです。これを行う理由はいくつかありますが、いくつかの一般的な理由があります。

  1. プロトコル変換 - サービスは、ニーズに合った正しいトランスポート バインディングを介して公開されていません
  2. サービス構成 - インターフェース操作が細かすぎて、ビジネスレベルの操作を表していません。
  3. 認証 - おそらく、使用しているエンドポイントの上に認証レイヤーが必要です。

したがって、サービスエンドポイントをラップする方法は、サービスをラップする理由によって異なります...

于 2012-04-30T12:40:21.130 に答える