3

PersonService私たちはいくつかのサービスに取り組んでいInsuranceServiceますPaycheckService。API を介してこれらのサービスにアクセスするために、コントローラーがあります。

PaycheckServiceがに関する情報を必要とする状況がありますPerson。現在、 と の間にレイヤーを使用していControllerますService。

  • PersonService から情報を取得する
  • PaycheckService から情報を取得する
  • 結合して結果を返します。

現時点では機能していますが、より多くのサービスが作成されるにつれて、サービス間の依存関係が増加します。これにより、この「レイヤー間」でより多くのロジック (マジック?) が発生します。

Dependency Injection と Service Locator に関する Fowler を読んでいて、役に立つかもしれません。(IoC には Unity を使用し、共有機能にはあちこちで DI を使用します)

問題は、サービスが他のサービスを消費できるようにするための優れた戦略は何かということです。

(メッセージング、インジェクション、REST、..)

ビジュアル

4

2 に答える 2

1

提供するコントラクトに基づいて、サービスの場所を容易にする責任を持つ単一のコンポーネントを作成できます。

このように、サービスは、消費したいコントラクトとサービスロケーターを知るだけで済みます。

ロケーターは、ネットワーク共有から構成リストを読み取るクラスから、永続ストアから構成を読み取るか、WS-Discoveryを使用してサービスを追跡する中央サービスに至るまで、あらゆるものにすることができます。

さらに、サービス間で交換されるタイプ/メッセージを指定するデータ コントラクトの共有セットを作成/設計することもできます。このようにして、サービスで使用されるタイプ間の変換の負担を軽減します。

編集

あなたはあなたの質問に追加しました：

(メッセージング、インジェクション、REST、..)

要件: 高速、疎結合

正直なところ、これらは戦略ではなく、設計の実装に役立つパターンとツールであるため、この追加はあまり有用ではないと思います。

また、何が高速であると考えているのか、疎結合のどの機能が最も重要なのかがわからないため、要件はあまり役に立ちません。

特定のガイダンスを探している場合は、質問をより具体的にするか、何かを構築して、遭遇したことについて質問してみてください。

于 2013-08-16T07:24:15.387 に答える