問題タブ [service-locator]

L.BugnionのMVVMLightFrameworkを使用しています。
顧客のIDなどのパラメーターをViewModelのコンストラクターに渡すために推奨されるアプローチにはどのようなものがありますか？

編集：各ViewModelに必要なパラメーターは、モデル間で共有されるものではありません。これは、各ビューモデルインスタンスに固有のものです。

NinjectをASP.NETMVC3RCアプリケーションに取り込もうとしています。

私が見つけたチュートリアルから、ServiceLocatorを次のように設定することになっています

ファイルにありGlobal.asaxますが、ASP.NET MVC3RCでこれを見つけることができないようです。これは別のものに変更されましたか？

IServiceLocator をクラス コンストラクターに挿入する方法は?

上記の構成を介してこれを実行しようとすると、ユニティがserviceLocatorとassemblyNameでコンストラクターを見つけられなかったため、 RequestHandlersFactory クラスを作成できないという例外が発生しました。

私は2つのインターフェースを手に入れました

および 2 つのクラス:

ここで、unity 構成ファイルを作成します。

私の設定コード:

StructureMap には、StructureMap.ObjectFactory を呼び出して構成が有効であることをテストする方法があります。

Unityにこれに相当するものはありますか?

私の現在のプロジェクトでは、SolrNet と OAuth.Net を使用しています。どちらのライブラリも Common Service Locator を使用します。SolrNet は、カスタム IoC コンテナー実装をロケーター プロバイダーとして設定します。OAuth.Net のロケーター プロバイダーは、私のコードで設定されています (現在、例で使用されているように、Windsor を使用しています)。問題はここから始まります。

実際には ServiceLocator.Current 静的プロパティ値を置き換えています。

何かアドバイス？このようなシナリオでのベスト プラクティスは何ですか?

前もってありがとう、Hristo

StructureMap の使用方法の一部を理解するのに苦労しています。特に、ドキュメンテーションでは、一般的なアンチパターン、コンストラクター注入の代わりにサービスロケーターとしてのみ StructureMap を使用することに関するステートメントが作成されています (Structuremap ドキュメントから直接のコードサンプル)。

それ以外の：

これは非常に短いオブジェクト グラフでは問題ありませんが、オブジェクトを何レベルも深く処理する場合、これは、より深いオブジェクトに必要なすべての依存関係を上から直接渡す必要があることを意味しますか? 確かに、これはカプセル化を破り、より深いオブジェクトの実装に関する多くの情報を公開します。

たとえば、Active Record パターンを使用しているとします。そのため、レコード自体を保存およびロードできるようにするには、データ リポジトリにアクセスする必要があります。このレコードがオブジェクト内に読み込まれる場合、そのオブジェクトは ObjectFactory.CreateInstance() を呼び出して、アクティブなレコードのコンストラクターに渡しますか? そのオブジェクトが別のオブジェクトの中にある場合はどうなりますか。さらに上から IRepository を独自のパラメーターとして取り込みますか? これにより、この時点でデータ リポジトリにアクセスしているという事実が親オブジェクトに公開されますが、これはおそらく外部オブジェクトが認識すべきではないことです。

任意の考えをいただければ幸いです。

サイモン

編集: インジェクションは最上層から開始する必要があるという意見があるようです。ActiveRecord は OuterClass に注入される ThingThatNeedsRecord に注入されます。これに関する問題は、実行時パラメーター (たとえば、取得するレコードの ID) を使用して ActiveRecord をインスタンス化する必要がある場合です。ActiveRecord を ThingThatNeedsRecord の一番上に挿入している場合、その時点で必要な id をどうにかして把握する必要があります (これにより、最上位レイヤーが実装されるべきではありません)、または部分的に構築された ActiveRecord が必要になります。後でIDを設定します。N 個のレコードが必要で、ThingThatNeedsRecord 内のロジックを実行するまでわからない場合、これはさらに複雑になります。

別のstackoverflowの質問（正確な質問は今はわかりません）の回答を読んで以来、私を悩ませてきた何かが、ユーザーが「Service Locatorを呼び出している場合、それは間違っています」のように言っています。

評判の高い人（10万人くらいだと思います）だったので、この人は何を話しているのか知っているのではないかと思いがちです。私は最初にDIについて学び始めてから、プロジェクトにDIを使用してきました。また、DIがユニットテストとどの程度関連しているかなどを学び始めました。それは私が今かなり快適なことであり、私は自分が何をしているのかを知っていると思います。

ただし、プロジェクトの依存関係を解決するためにServiceLocatorを使用している場所はたくさんあります。かつての代表的な例は、私のModelBinder実装からのものです。

典型的なモデルバインダーの例。

実際の実装ではありません-簡単な例です

ModelBinder実装では、バインダーが最初に要求されたときに新しいインスタンスが必要になるため、この特定の実装のコンストラクターで依存性注入を使用することはできません。

私の多くのクラスではこのようになっています。もう1つの例は、Webサイトでキャッシュオブジェクトの有効期限が切れるたびにメソッドを実行するキャッシュ有効期限プロセスの例です。私はたくさんのデータベース呼び出しを実行しますが、そうではありません。そこでも、必要な依存関係を取得するためにServiceLocatorを使用しています。

私が最近抱えていたもう1つの問題（ここに質問を投稿しました）は、すべてのコントローラーにDIを使用するIDataContextのインスタンスが必要でしたが、1つのアクションメソッドにはIDataContextの別のインスタンスが必要でした。幸いなことに、Ninjectは名前付きの依存関係で救助に来ました。しかし、これは恨みのように感じられ、実際の解決策ではありませんでした。

少なくとも、関心の分離の概念はかなりよく理解していると思いましたが、依存性注入とサービスロケーターパターンの理解方法に根本的な問題があるようです。それが何であるかはわかりません。

私が現在理解している方法（これも間違っている可能性があります）は、少なくともMVCでは、ControllerFactoryがコントローラーのコンストラクターを探し、Service Locator自体を呼び出して必要な依存関係を取得し、それらを渡すことです。ただし、 、すべてのクラスと、それらを作成するためのファクトリがないものは理解できます。したがって、いくつかのServiceLocatorパターンは許容できるように思えます...しかし...

1. いつ受け入れられないのですか？
2. Service Locator Patternの使用方法を再考する必要がある場合は、どのようなパターンに注意する必要がありますか？
3. ModelBinderの実装は間違っていますか？もしそうなら、私はそれを修正するために何を学ぶ必要がありますか？
4. この1人のユーザーの方針に沿った別の質問で、MarkSeemannはAbstractFactoryを推奨しました-これはどのように関連していますか？

それだけだと思います。理解に役立つ他の質問は思いつきませんが、追加情報をいただければ幸いです。

DIがすべての答えではない可能性があることを理解しており、DIの実装方法をやりすぎている可能性がありますが、単体テストなどで期待どおりに機能しているようです。

実装例を修正するためのコードを探しているのではありません。欠陥のある理解を修正するための説明を探して、学びたいと思っています。

stackoverflow.comにドラフトの質問を保存する機能があればいいのにと思います。また、私はたくさんのことを求めていると思うので、この質問に答える人は誰でも、この質問に答えるのに適切な評判を得られることを願っています。前もって感謝します。

Unityを使用してアプリサーバー上のサービスを管理していますが、何らかの理由で「GetAllInstances」メソッドを機能させることができません。奇妙なことに、同じタイプの「GetInstance」は正常に機能しているようです。

構成は次のとおりです。

サーバーの起動時に、IServiceの構成済みインスタンスをすべて取得して初期化できるようにする必要があるという考え方です。

私が言うように、シングルは機能しますが、getallは何も返しません。構成からIAtomCommandServiceマッピングを削除し、IServiceを使用しただけでも、機能しません。私がこれでどこが間違っているのかについてのアイデアはありますか？

SolrNetをvb.net2.0で使用していますが、solrをインスタンス化できないようです。

Dim solr As ISolrOperations（Of PMWProperty）= ServiceLocator.Current.GetInstance（Of PMWProperty）（）

例外をスローします：

[KeyNotFoundException：指定されたキーがディクショナリに存在しませんでした。] System.ThrowHelper.ThrowKeyNotFoundException（）+28 System.Collections.Generic.Dictionary`2.get_Item（TKey key）+7456108 SolrNet.Utils.Container.DoGetInstance（Type serviceType 、文字列キー）+22 Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance（Type serviceType、文字列キー）+47

[ActivationException：タイプPMWProperty、キー ""のインスタンスを取得しようとしたときにアクティブ化エラーが発生しました]Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance（Type serviceType、String key）+104 Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance（）+5

solrスキーマに一致するフィールドがいくつかあるPMWPropertyクラスがあります。solr url（localhost：8983 / solr）を介してクエリを実行できますが、コードで機能させることができません。

それはどのキーを見ていますか？例外はキーが「」であると言っているようですが、それはどうあるべきですか？なぜキーが必要なのですか？

@EJB アノテーションの使用中に発生する可能性のあるパフォーマンスの問題に関連する質問があります。次のシナリオを想像してください

他の Bean に多くの依存関係を持つ Bean があります。EJB 仕様によると、MyBean1Remote を他の Bean に注入したい場合、コンテナーはプールから必要なすべての依存関係を取得し、それを MyBean1Remote に注入してから、MyBean1Remote スタブへの参照を注入する必要があります。

したがって、次のシナリオでは、コンテナーは 20 個の ejbs (myBean1 とその 19 個の依存関係) を予約する必要があります。

ほとんどの場合、myBean1 の各ビジネス メソッドごとに 1 つの依存関係のみを使用するとします。その結果、その Bean を注入するたびに、コンテナーに多くの不要な EJB を強制的に予約させます。また、リモート Bean で操作していると仮定すると、依存する Bean を注入する前に、おそらくコンテナーも負荷分散アルゴリズムを実行する必要があります。

質問:

1. クラスタ環境で運用している場合、不要なリソース予約などの過剰なパフォーマンスの問題が発生することはありませんか?

2. このアプローチでは、本当に必要なときに特定の EJB を要求するため、古き良き ServiceLocator の方が優れたソリューションになる可能性があります。