0

WCFが関係するサーバープロジェクトとクライアントプロジェクトの両方に必要なサポートクラスのセットを追加/含める/参照する方法がわかりません。

私のC＃ソリューションでは、次のようになっています。

  • サーバータイプのものを実行するサーバープロジェクト
  • GUIタイプのものを実行するクライアントプロジェクト
  • ネットワークで渡されたデータオブジェクトのクラス定義を含むWCFライブラリ

サーバープロジェクトは、通常の参照を使用してWCFライブラリを含めます。クライアントプロジェクトは、WCFライブラリへのサービス参照を使用します。

私の問題は、WCFライブラリに含まれているオブジェクト定義を使用するサーバープロジェクトとクライアントプロジェクトの両方で必要なユーティリティクラスがいくつかあることです。これらのクラスの2つの（同一の）コピーをサーバープロジェクトとクライアントプロジェクトに配置したくありません。1つのコピーを維持することをお勧めします。それはクラスライブラリを使用することを示唆しますが、参照はどのように機能しますか？この新しいクラスライブラリにはWCFライブラリへの標準参照があり、サーバープロジェクトとクライアントプロジェクトの両方がこの新しいクラスライブラリを順番に標準参照する必要があります。しかし、クライアントプロジェクトには、WCFライブラリに含まれるデータオブジェクトクラスの2つの異なる定義が含まれているのではないでしょうか。これらのユーティリティクラスを他にどのように含める必要がありますか？

4

1 に答える 1

1

サービス参照アプローチを使用すると、WCFの初期の生活を簡素化するコードが生成されるため、WCFを使用する際の最初の負担が軽減されます。ただし、WCFの使用に慣れ、サービス参照が実際に何を行っているかを理解するにつれて、サービス参照アプローチがヘルプよりも障害になる場合があることに気付き始めます。

たとえば、私の場合、3つの異なるプロジェクト（2つのC＃プロジェクトと1つのマネージC ++プロジェクト）で使用されるWCFサービスがありました。WCFサービスインターフェイスを更新するたびに、これら3つのプロジェクトのそれぞれでサービス参照を再生成する必要がありました。それはすぐに私にとって頭痛の種になりました。

さらに（そしてあなたはこれに遭遇しています）、サービス参照アプローチはDataContractクラスの構造のみを扱い、それらの動作は扱いません。したがって、サーバー側で便利なメソッドをDataContractクラスに追加する場合、その動作はメタデータ交換（MEX）操作を介して伝達されないため、クライアント側で手動で追加する必要があります。

その時、私はこのビデオに出くわしました。その中で、Miguel Castroは、サービス参照アプローチの使用を完全に回避するための説得力のある事例を示しています。そして、彼の議論を検討するとき、それは本当に非常に理にかなっています。

彼の推奨事項に基づいて、DataContractクラスとそれらを操作するクラスを、クライアントとサーバーの両方から直接参照される（サービス参照なし）クラスライブラリに配置することをお勧めします。ビデオからわかるように、クライアント側のコードを自分で記述し、WCFインターフェイスが変更されたときに更新するのは非常に簡単です。

私はこのアプローチを2か月間使用してきましたが、このソリューションは、サービス参照アプローチを使用するよりも、WCFの使用方法に対してはるかに柔軟であることがわかりました。

于 2009-09-22T01:01:10.843 に答える