問題タブ [service-locator]

IoC コンテナーを抽象化する方法としてCommon Service Locatorを検討してきましたが、このタイプのこのタイプに強く反対する人がいることに気付きました。

人々はそれを決して使用しないことを勧めますか? いつも使ってる？または時々それを使用しますか？場合によっては、どのような状況で使用し、どの状況で使用しないか.

FlexとCairngormを初めて使用します。ServiceLocatorを使用しているときに、問題が発生します。エラー：C0001E：インスタンス化できるServiceLocatorインスタンスは1つだけです。

私のコードは次のようなものです：

Serives.mxmlの場合：

Delegate.asには、スニペットがあります。

Main.xmlでは、次のようなスニペットがあります。

この素晴らしい小さなエラーメッセージは、httpserviceを必要とするモジュールの2番目のインスタンスをロードした瞬間にポップアップします。

別のフレームワークに切り替えずにこの問題を解決する方法はありますか？

幸運をお祈りしています、

中国からのシュオ

コードを分離するために、サービス ロケーターを使用できますが、これはグローバル変数/状態と同じではありませんか?

これらはしばしばインターフェイスから実行されることを知っているので、インターフェイスを渡して具体的なクラスを取得しますが、それでも私の質問は残っています。

例えば：

ここで、クラスは別の場所で作成された MyType を必要としますが、MyType をチェーンを介して (コンストラクターなどを介して) 渡すのではなく、この方法で取得します。

_{私は開発者としてのプロとしてのキャリアの早い段階でこの質問をしましたが、それ以前はこのパターンに出くわすことはありませんでした。Anthony は、サービス ロケーターに関する私の意見を明確にしました (したがって、現在はこれが選択された回答です)。提供されたリンクは良い出発点ですが、これまで何度も自分の質問に答えるには、それらはグローバルな状態として機能するため、避ける必要があります。標準の依存性注入を好む;)}

デザイン可能な .NET コンポーネントを作成するときは、既定のコンストラクターを指定する必要があります。IComponentのドキュメントから:

コンポーネントになるには、クラスは IComponent インターフェイスを実装し、パラメーターを必要としないか、タイプ IContainer の単一のパラメーターを必要とする基本的なコンストラクターを提供する必要があります。

これにより、コンストラクター引数を介して依存性注入を行うことができなくなります。(追加のコンストラクターを提供することもできますが、デザイナーはそれらを無視します)。

• サービスロケーター

  依存関係の挿入を使用しないでください。代わりに、サービス ロケーター パターンを使用して依存関係を取得してください。これは、IComponent.Site. GetServiceはそのためのものです。必要な依存関係で構成できる再利用可能な ISite 実装 (ConfigurableServiceLocator?) を作成できると思います。しかし、これはデザイナーのコンテキストではどのように機能するのでしょうか?

• プロパティによる依存性注入

  プロパティを介して依存関係を注入します。デザイナーでコンポーネントを表示するために必要な場合は、既定のインスタンスを提供します。注入する必要があるプロパティを文書化します。

• Initialize メソッドで依存関係を注入する

  これはプロパティを介した注入によく似ていますが、注入する必要がある依存関係のリストを 1 か所に保持します。このようにして、必要な依存関係のリストが暗黙的に文書化され、コンパイラーはリストが変更されたときにエラーを支援します。

ここでベストプラクティスは何ですか？どのようにしますか？

---

edit : コンポーネント全般に関する質問をするつもりだったので、「(例: WinForms UserControl)」を削除しました。コンポーネントはすべて制御の反転に関するものなので ( UMLv2 仕様のセクション 8.3.1 を参照)、「サービスを注入してはならない」というのは良い答えではないと思います。

---

編集2：最終的にマークの答えを「得る」には、WPFとMVVMパターンをいじる必要がありました。ビジュアル コントロールは確かに特殊なケースであることがわかりました。デザイナー サーフェイスでの非ビジュアル コンポーネントの使用に関しては、.NET コンポーネント モデルは基本的に依存性注入と互換性がないと思います。代わりに、サービス ロケーター パターンを中心に設計されているようです。おそらく、これは、.NET 4.0 でSystem.ComponentModel.Composition名前空間に追加されたインフラストラクチャで変わり始めるでしょう。

Service Locatorクラスを使用して、バインドするWPFページのViewModelを提供する場合。ViewModelsはシングルトンスコープまたはファクトリスコープのどちらにする必要がありますか？一般的に、WPFアプリケーションの方が良いアイデアはありますか？

Silverlightでは、シングルトンはユーザーコントロールであり、フォアグラウンドに出入りするだけのページに適していることを認識しています。しかし、このパターンを適用しようとするまで、ロードされるたびにページのインスタンスとそれぞれのVMを更新してきました。

私と私の同僚は、各オプションのすべての長所と短所を経験しましたが、私たちのシナリオにとってより良いオプションである叫び声は何もありません。

ありがとう。

私は依存性注入フレームワークについて読んでいます。私は、懸念事項を分離し、オブジェクトにコアワークを任せるというアイデアに本当に恋をしました。これは、間違いなく優れた長年の設計原則です!

しかし、DI フレームワークについて読めば読むほど、次のことが心配になります。

ポイント 2 だけですが、顧客が何百万ドルも費やして製品のトレーニングを行っているのを見てきましたが、その重要な部分は構成ファイルに触れないようにする方法でした。管理者は現在、これらの構成ファイルを恐れています。

それにもかかわらず、アプリケーションの開始時に必要なすべての「グローバル」サービス (アプリケーション ホストまたはアプリケーション コンテキストなど) を適切に組み立てることができる Service Locators と呼ばれる別のパターンを目にします。このサービス ロケータをグローバルに利用できるようにすると、出来上がりです!

ただし、(誰に知られている?) いくつかの基準に基づいて複数のタイプの「グローバル」サービスが必要な場合に、Service Locator アプローチを使用すると柔軟性が低下することがわかります。

ですから、ここで、どちらの方向に進むべきかについて、以前よりも混乱しています。設計原理はとても気に入っていますが、既存のフレームワークの複雑さにうんざりしています!

私の懸念は本物ですか？他の誰かが同じように感じますか？もしそうなら、そのような非常に圧倒的な「フレームワーク」に代わるものはありますか?

シングルトンに対してサービスロケーターを使用することの長所と短所は何ですか？シングルトンは悪いことを読んだことがありますが、ServiceLocatorが一般的に物事を行うためのより良い方法であるかどうか疑問に思っています。

私は、Web アプリに IoC を実装するための詳細を調べてきましたが、Microsoft.Practices.ServiceLocation を活用する方法で行いました。私は特に Autofac と asp.net の統合を使用していますが、他のコンテナーに対して自分自身を開いたままにしたかったのです。この質問の行に沿って、Web アプリ コードでコンテナーにアクセスする方法が心配でした。

主に解決するインターフェイスを定義する「コア」ライブラリがあります。このコア ライブラリは、私の Web アプリや他のアプリでも使用されています。共通のインターフェースを定義すると非常に便利です。これは、IoC コンテナーへのアクセスを配置するのに最適な場所だと思い、静的クラスを使用して実行しました。トリックは、コンテナを静的クラスに注入することです。

Web 環境ではコンテナがリクエストごとに異なる可能性があるため注意が必要ですが、Web 以外のアプリでは常に同じになる可能性があります。最初はコンテナにメソッドを直接注入しようとしましたが、次の Web リクエストですぐに失敗しました。だから私はこれを思いついた：

今私のglobal.asax.csでこれを行います：

そして、依存関係を解決するための呼び出しは次のようになります

したがって、特定のコンテナーを渡すのではなく、コンテナーを取得する方法を知っているデリゲートを渡します。非 Web アプリケーションの場合、デリゲートはおそらく build() が提供するものを返すだけです。

専門家への私の質問は、これは理にかなっていますか? コンテナー製品が何であるか、またはコンテナー自体がどこから来たのかを知らなくても、依存関係を解決できるものにたどり着く簡単な方法があります。どう思いますか？

Guiceスタイルの構成システムを使用するサービスロケーターパターンを見た/書き込もうとした人はいますか？

現在、コマンドパターンを使用するGWTプロジェクト（たまたまGWT-RPCを使用）があり、RPCサーブレットは次のようになっています...

executeメソッドの現在の実装では、これを行います...

私がやりたいのは、巨人のifステートメントを取り除く方法を見つけることです。ActionImpl1のクラスをTransactioNServiceの別の実装に委任する必要があることを登録する何らかの方法が必要になります。

何か案は？キーがActionのクラスで、値がServiceImplのクラスであるHashMapにエントリを追加することを考えていました。1つはServiceImplクラスへの参照があり、Guiceを使用してTransactionServiceのインスタンスを取得できます。

複数の WCF サービスを使用する必要がある Silverlight アプリケーションがあります。サービスのエンドポイント (url) は、Silverlight アプリケーションまたは構成ファイル内にハードコーディングできません。それらは、それ自体が WCF サービスである Service Registry から照会する必要があります。問題は、実際のサービス プロキシのインスタンスを作成する前に、非同期呼び出しを使用してサービス エンドポイントをクエリする必要があることです。応答を待つか、実際のサービスへの呼び出しをブロックする良い方法が思いつきません。Silverlight アプリケーションで Service Registry / Service Locator パターンを使用する最良の方法は何ですか?