1

私が取り組んでいるプロジェクトには、次のような構造が必要です。

{BasePrefix}/Application/{id}/Security/Users/{userId}
{BasePrefix}/Application/{id}/Objects/{objectId}
etc.

Application.svc は最終的に私の WCF Web サービスになります。私は彼らに次のように説得しようとしました：

{BasePrefix}/Security/Application/{id}/Users/{userId}

これにより、複数の WCF Web サービスを Security.svc、Objects.svc などとして使用できるようになります。

彼らはまだすべてをアプリケーションの下に置きたいので、すべてのサービス メソッドを 1 つのファイルに入れるのではなく、機能ごとに分割し、部分クラスを使用してすべてを 1 つのリソースに結合したいと考えました。

ここでこれを行う方法に関する記事を見ました: http://www.meineck.net/2008/04/wcf-hosting-multiple-wcf-services-as.html

ただし、その記事の開発者は Net TCP バインディングを使用しているため、これが WebHttpBinding で機能するかどうか、および IIS が複数のリソースをどのように処理するかはわかりません。

誰かがこれをしましたか？リンクした記事は良いリソースですか? または、同じ結果を達成するためのより良い代替方法はありますか?

4

1 に答える 1

0

netTcpBindingリンクされた記事の方法論は適切であり、 ( などを含むwebHttpBinding)以外のバインディングでも機能しますwsHttpBinding。

ただし、あなたがしようとしているのは、(おそらくUriTemplateプロパティを使用して) URL 書き換えスキームを使用していると思います。これは、その記事が実際に話していることとは微妙に異なります。これは、同じサービスによる複数のインターフェースの作成と実装、および各インターフェースを独自のエンドポイントにマッピングすることを指しています。

このアプローチは、単一のエンドポイントでは機能しません。したがって、エンドポイントがの場合、構成内の 1 つのインターフェイス(たとえば) に{BasePrefix}/Applicationのみマッピングできます。IApplicationService

あなたの場合、エンドポイントが 1 つしか必要ないため、複数インターフェイス ルートに進むことはできないと思います。したがって、すべてのメソッドを備えた単一のモノリシック インターフェイスが引き続き必要ですが(醜い)、理論的には部分クラスを使用して、これらのメソッドの実装を論理グループに分割できます。より良いですが、正確には理想的ではありません。

あなたは最初の評価で正しい軌道に乗っていました。スキームが次のようになっている場合:

{BasePrefix}/Security/Application/{id}/Users/{userId}
{BasePrefix}/Repository/Application/{id}/Objects/{objectId}

次に、複数のサービスを使用するか、複数のインターフェイスを実装して複数のエンドポイントをホストする単一のサービスを使用するかのいずれかのアプローチを使用できます。

その記事のコード/構成が実際に行うように設計されているのは、単一のサービス インスタンスが複数のエンドポイントをホストできるようにすることです。これを行う主な理由は、サービス間で多くのコードを複製する必要がある場合です。残念ながら、それはここでの目標ではないため、提案された URI スキームをさらに推し進めるか、モノリシックなサービス コントラクト (インターフェイス) に対処し、ディレクティブや部分クラスを通じて実装をクリーンに保つために最善を尽くす必要があります。#region

于 2010-04-01T15:03:43.293 に答える