単一のエンドポイント アドレスで多数のサービス メソッドを公開する wcf サービスがあります。これまでは、すべてのサービス メソッドが 1 つのサービス コントラクト クラスに実装されていました。このサービス コントラクト クラスは、いくつかのサービス コントラクト インターフェイスを実装します。ここで、コントラクト クラスが大きくならないように、サービス コントラクト メソッドの実装をいくつかのクラスに分割したいと思います。ServiceHost でセルフ ホスティング シナリオを使用します。ServiceHost は、サービス メソッドを実装する単一の型の型を取るだけなので、すべてをこのクラスに実装する必要があるようです。もちろん、メソッドの中身はいくつかのクラスに分解できます。しかし、メソッドをいくつかのクラスに分割する方法もありますか?
3 に答える
サービスを部分クラスとして実装すると、実装を複数のファイルに分割できます。
要件が単一のエンドポイントと単一のインターフェースを保持することである場合、それを分割する他の方法はありません。作成する 1 つのクラスは、すべてのインターフェースを実装する必要があります。
サービスの実装をできるだけシンプルに保ち、各メソッドを実際の実装に操作を委譲するワンライナーにすることをお勧めします。これにより、複数のクラスに分割できます。おそらく、操作ごとに 1 つ作成することは理にかなっているでしょうか? これは、私が以前に使用して成功したパターンです。
それぞれ独自のロジックを背後に持つサービス コントラクトを必要な数だけ作成できます。
このアプローチの利点は、お望みのように、関連する関数を論理的にグループ化できることです。
欠点は、呼び出し元のクライアントが、関数を呼び出すときに使用するサービスを知る必要があることです。
サービスの操作数を制限することは良いアプローチです。現時点であなたのシナリオを理解しているように、複数のサービス契約を実装する単一のサービス実装があります。これは、サービスに既に複数のエンドポイントがあることを意味します。各エンドポイントは単一のコントラクトを公開します。その場合、クライアントは必要なコントラクトごとに個別のプロキシを作成する準備がすでに整っています。
ここで、サービス実装クラスを複数のサービス実装に分割したいと考えています。各サービス実装は、サービス コントラクトの 1 つ (またはより小さなセット) を実装します。これには、ホスティング アプリケーションの変更が必要になります。サービスの実装ごとに個別の ServiceHost が必要になります。また、サービスの実装ごとに個別の構成と一意のアドレスが必要になります。
クライアント側は新しいサービスで再作成できますが、エンドポイントのアドレスを変更するだけで機能するはずです。