問題タブ [service-locator]

IServiceLocator、IMvcServiceLocator、IDependencyResolverなどと少し混乱しています...

ASP.NET MVC 3 RTMでサービスを見つける方法は何ですか？

必要なのは次のようなものにアクセスすることだけです

どこからでも（別のアセンブリを含む）。

編集：例

私のウェブアプリは一種のモジュラーアーキテクチャを持っています。テーマはモジュールの1つの側面です。各テーマは個別のクラスライブラリです。テーマに必要なサービスを知ることはできません。たとえば、一部のビューにタグクラウドウィジェットが表示され、そのウィジェットにはTagRepositoryのインスタンスが必要な場合があります。

現在、Windsor for IoCを使用しており、そのコンテナーをモジュール用に公開できます。しかし、すべてのモジュールをWindsorに依存させたくはありません。モジュールはとにかくそれへの参照を必要とするので、標準のMvcライブラリに解決策があるかどうか知りたいです。

ちょっと、そこ。ここ
で Service Locator パターンについて 読んだ後、静的メンバーのみを持つクラスが本当に進むべき道なのか、それとも通常の c のようなインターフェイスが適切ではないのかを考えさせられました。人々がキーワードを必要としないのに、いつも放り投げているのを目にします。 リンクされたページから取得した静的メンバー クラスの例:class

これもできる方法です：

どちらの例も、 と を使用してまったく同じ方法で呼び出すことができLocator::GetAudio()ますLocator::Register(...)。上記のいずれかが他のものよりも優れていますか? 彼らは同じですか？これを達成するためのより良い方法はありますか？それとも個人的な好みの問題ですか？助けてくれてありがとう。:)

私は現在、DIとSLの長所と短所を比較検討しています。しかし、私は次のキャッチ22に気づきました。これは、すべてにSLを使用し、各クラスにIoCコンテナーのみを注入する必要があることを意味します。

DIキャッチ22：

Log4Netなどの一部の依存関係は、単にDIに適合しません。私はこれらのメタ依存関係を呼び出しており、コードの呼び出しに対して不透明である必要があると感じています。私の正当な理由は、単純なクラス「D」が元々ロギングなしで実装され、その後ロギングを必要とするようになった場合、依存クラス「A」、「B」、および「C」は、何らかの方法でこの依存関係を取得し、 「A」から「D」（「A」が「B」を構成し、「B」が「C」を構成すると仮定）。1つのクラスにログインする必要があるという理由だけで、コードを大幅に変更しました。

したがって、メタ依存関係を取得するには不透明なメカニズムが必要です。シングルトンとSLの2つが思い浮かびます。前者には、主に厳密なスコープ機能に関して既知の制限があります。せいぜいシングルトンは、アプリケーションスコープ（つまり静的変数）に格納されているAbstractFactoryを使用します。これによりある程度の柔軟性が得られますが、完全ではありません。

より良い解決策は、IoCコンテナーをそのようなクラスに注入し、そのクラス内からSLを使用して、コンテナーからのこれらのメタ依存関係を解決することです。

したがって、キャッチ22：クラスにIoCコンテナーが注入されているので、他のすべての依存関係も解決するためにそれを使用してみませんか？

私はあなたの考えを大いに感謝します:)

アプリケーションでこの Service Locator パターンを使用し、Singleton として実装しました。

サービス ロケータ パターン

そして今、私はそれをテストしたい.これまでのところ、私のクラスがシングルトンであることを確認するテストを書きました. 私もこのテストを書きました：

しかし、IRandomService を使用するつもりはないので、最後のテストはあまり好きではありません。GetService<T>そのため、例外がスローされることをテストするためのより良い方法を探しています。また、このクラス用に記述できる関連テストが他にあるかどうかも知りたいです。

NUnitの最新バージョンを使用しています。

乾杯

マルチモジュールのGWTプロジェクトがあり、ServiceLocatorsを使用したいと思います。私は3つのモジュールを持っています：

• 「クライアント」は共有に依存
• 「共有」
• 「サーバー」は共有に依存

私はServiceLocatorを次のように書きました：

ServiceLocatorにはパッケージcom.google.gwt.requestfactory.sharedがあるため、このクラスを「共有」モジュールに配置しました。ただし、TreeServiceはサーバーからBeanを返し、Springなどと対話する必要があるため、TreeServiceは「server」モジュールに実装されているため、コンパイルするとエラーがスローされます。

TreeServiceLocatorを実装するモジュールはどれですか？また、「共有」モジュールから「サーバー」をインクルードしようとすると、Mavenは循環依存エラーをスローします。

ありがとうございました！

多くの蹴りと叫び声を上げた後、依存関係が大きくなるにつれてSLがどれほどクリーンに見えるかもしれないにもかかわらず、私はDIを受け入れ始めています。

ただし、IMOには、DIに関して重要なショーストッパーがまだあります。

オブジェクトのインスタンス化を制御できない場合、DIは使用できません。ASP.NETの世界では、例にはHttpModule、HttpHandler、Pageなどがあります。

上記のシナリオでは、依存関係を解決するために静的なサービスの場所に頼ります。通常はHttpContext.Current、を介して、現在のスレッドから常にスコープを推測します。したがって、ここで静的SLを使用する場合は、他の場所でも使用してみませんか？

答えは次のように簡単ですか：歯を食いしばって、必要に応じてSLを使用します（上記のように）が、DIを支持してみてください。もしそうなら：静的SLを一度だけ使用すると、アプリケーション全体の一貫性が損なわれる可能性がありますか？本質的に他の場所でDIのハードワークを元に戻しますか？

私は本当に DI/IoC のことにはまってしまいました。ただし、必要なパラメーターなしのコンストラクターを持つクラスを実装する継承されたクラスがいくつかあるため、サービスロケーターを使用して必要なものを取得します。

完璧に動作します。ただし、MVC3 DependencyResolver も使用しているため、次のことを行うしかありません。

DependencyResolver は MVC アプリ内で使用され、ServiceLocator はさまざまなクラス ライブラリ全体で使用されます。

これはこれを行うための理想的な方法ですか？何か不足していますか？

アップデート

上記の例では、クラスはカスタム asp.net メンバーシップ プロバイダーです。asp.net メンバーシップ プロバイダー ファクトリでは、カスタム プロバイダーにパラメーターのないコンストラクターが必要なため、サービス ロケーターを使用して内部で使用するリポジトリを挿入する必要があります。

Unity ServiceLocator を介して解決したい ViewModel クラスがありますが、viewModel にはコンストラクターへのパラメーターが必要です。パラメータの型は、一部のサービス実装ではなく、アプリケーション (Customer オブジェクト) のエンティティの 1 つです。Unitycontainer 自体に対するコーディングで、次のようなパラメーターを渡すことができることを知っています。

ただし、コンテナーに直接アクセスできない場合は、次のように ServiceLocator を経由する必要があります。

ただし、2 番目のアプローチを使用すると、ServiceLocator にパラメーターを渡す方法がありません。これを行う方法はありますか？ServiceLocator から Container のインスタンスを取得してそれを使用するのは「間違っている」のでしょうか?

依存性注入にServiceLocatorを使用すべきではないと人々が言うのを聞いています。では、サービスロケーターに依存せずに、どの程度正確に依存関係を注入しますか？IoCコンテナーを試してみたいのですが、アンチパターンに陥りたくありません。

すべてのクラスが常に最も深いクラスへの依存関係チェーンを持つ1つの場所があるように、すべてを設定する必要がありますか？（私/それがまったく理にかなっている場合）

選択したIoCコンテナへの依存関係ですべてのコードを散らかすのは正しくありませんか？

では、コンテナをどこで「使用」しますか（再解決のため）？そして、コードが進む限り、どのようにしてすべてを解決することができますか？それは、フロントレイヤーまでのすべてのレイヤーを介してインターフェイスを使用することにより、すべてを正しい方法で設計することの一部ですか？

それとも私はただポイントを逃していますか？

私はアンチパターンに陥りたくないので、いくつかのヒント/注意が必要であることを思い出させてください。

ServiceLocator パターンを実装するクラスを作成しています。

今、私はいくつかの質問があります：

1.) このクラスはどこから呼び出す必要がありますか? app.xaml.cs は wpf のようなことをしていますか?

2.) サービスを登録する必要がありますか? はいの場合、どこで登録すればよいですか?

3.) サービス "ICustomerService" の遅延初期化を行う場合、なぜそれに対して Register(T service) メソッドを作成する必要があるのでしょうか? それは二重の仕事です。

4.) サービスロケータを取得する必要がありますか?

アップデート

現時点では、個人的な目的のためにDIツールをレイプする必要があると感じています=>

App.xaml.cs => ここで、MainWindow を作成し、そのデータ コンテキストを MainViewModel.cs に設定します。

MainViewModel.cs => ここで、LessonPlannerDailyViewModel や LessonPlannerWeeklyViewModel などの特定の Controller/ViewModel に必要なデータをプリロード/セットアップします...

もう 1 つの ViewModel は、LessonPlannerDailyViewModel.cs => ここで、コンストラクターでいくつかのサービスを受け取る PeriodViewModel オブジェクトのバインド可能なコレクションを作成します。次のコードの後の次の段落で、サービスを再度取得する ONE PeriodViewModel によって作成された DocumentListViewModel.cs を参照してください - MainViewModel で作成したものと同じです... -

PeriodViewModel.cs => DataGrid のすべての DataRow には期間があり、期間には DocumentListViewModel にテンプレート化された特定のセル データがあります - 期間 1 には N ドキュメントがあります。

DocumentListViewModel.cs => ここで、ドキュメントを追加/削除/開くためのコマンドをセットアップします。これは、documentService/documentRepository で実行できます。

問題をまとめると: 上からサービスをカスケードする一連のオブジェクトが見えますか?

MainViewodel -> LessonPlannerDailyViewModel -> PeriodViewModel -> DocumentListViewModel

静的サービスロケーターを使用していない場合、サービスをカスケードするときにサービスのインスタンスを1つしか確保できないため、それらをカスケードする必要があります...

ここのDIツールは、MVVMパターンに従ってwpfアプリを具体的に実行するのにどのように役立ちますか?