問題タブ [service-locator]

どちらのパターンも、制御の反転の原則の実装のように見えます。つまり、オブジェクトはその依存関係を構築する方法を知っているべきではありません。

依存性注入 (DI) は、コンストラクターまたはセッターを使用して依存関係を「注入」しているようです。

コンストラクター インジェクションの使用例:

Service Locator は「コンテナ」を使用しているようで、依存関係を結び付けて foo にバーを与えます。

Service Locator の使用例:

依存関係はオブジェクト自体にすぎないため、これらの依存関係には依存関係があり、さらに多くの依存関係が存在します。このようにして、コントロールコンテナ（またはDIコンテナ）の反転が生まれました。例: Castle Windsor、Ninject、Structure Map、Spring など)

しかし、IOC/DI コンテナはサービス ロケータとまったく同じように見えます。DIコンテナと呼ぶのは悪い名前ですか？IOC/DI コンテナはサービス ロケータの一種ですか? 多くの依存関係がある場合に主に DI コンテナーを使用するというニュアンスはありますか?

現在、DI/IOC を使用しており、追加のパラメーターをコンストラクターに渡す必要がある場合は、ファクトリ クラスを使用します。

ここでの問題は、大量のファクトリ クラスを作成することになり、人々はそれらの使用方法を常に知っているとは限らないことです (彼らは自分でそれらを新しくすることもあります)。このようにクラスをコーディングすることの最大の欠点は何ですか:

長所: ファクトリ クラスを必要とせずにコンストラクターを安全に使用できるようになりました。短所: Service Locator を参照する必要があります (テスト容易性については心配していません。コンテナーのバッキング サービスとしてモック コンテナーを使用するのは簡単です)。

これをすべきではない理由の大きな悪臭がそこにありますか?

編集：少し考えた後、プライベートコンストラクターを持ち、Factory クラスをネストすることで、実装とファクトリーを一緒に保ち、人々がクラスを不適切に作成するのを防ぐことができると思いました。SL が汚れていることについてのすべてのポイントはもちろん真実なので、以下の解決策は私を満足させます。

これは私の前の質問へのフォローアップの質問です。

ServiceLocator クラスのテスト ケースを作成しようとしていますが、次のエラーが表示されます。

私のテストケース:

上記のコードは、getInstance()次のようなメソッドで失敗します。

ServiceLocatorフロントエンドからアプリケーションをテストしても問題がないため、これがうまく機能することはわかっています。このテスト ケースを書いている唯一の理由は、DAOをテストしたいからです。そして、私が DAO をテストするには、 ServiceLocator( JUnitから) 動作する必要があります。

エラーメッセージの意味がわかりません。誰かが私が試してうまくいくことを提案したいですか?

編集: ServiceLocator コンストラクター

CodeCampServer ソース コードには、汎用のStaticFactoryが含まれています。

これは、フレームワークが Dependency Injection でうまく機能するメカニズムの重要な部分であると推測しています。

そのサブクラスは、DefaultUnconfiguredState を使用して静的アクセスを提供します。つまり、依存関係解決メカニズムが動作するものに置き換えることができる Default Unconfigured State への静的アクセスを提供します。

これに関するドキュメントを見つけることができませんでした...

本に良い説明はありますか？(Amazonからの発送待ちです…)

...または、これが何であるか、およびこのパターンを採用するのが賢明かどうかについて、他の誰かが良い解説を提供できますか?

アップデート

Jeffrey Palermo がこの質問に答えたので、MVC2 in Action の (進行中の) 原稿で、このパターン/スタイルが説明され、ドメイン層を無視するためにリポジトリを見つけるために使用されるファクトリを使用して示されていることがわかります。持続性の懸念。(第 23 章を参照)。

デフォルトでは、このファクトリを使用すると例外がスローされます。

「リポジトリを作成する方法の知識は、ファクトリにはありません。このファクトリは、リポジトリを返す機能を表すだけです」

この例では、リポジトリ インターフェイスの具体的な実装を初期化するためのいくつかのメカニズムの 1 つを使用できます。本の例では、簡単にするために IOC コンテナーを使用しないことを選択し、一部の起動ロジックで明示的に提供しています。

「重要なことは、Core プロジェクトも UI プロジェクトも、本質的に純粋にインフラストラクチャであるインフラストラクチャ プロジェクトまたはライブラリを参照してはならないということです。アプリケーションの残りの部分がどのようにデータアクセスが発生しています」

この新しい章のサンプル コードに関する最後の注意点は、Factory が静的ではなくなったことです (少なくとも、外部に面したインターフェイスに関する限り)。

更新 2

Palermo 氏は、Abstract Factory のこの特定のスタイルについてさらにブログを書いています(OrderShipperFactory の実装を参照してください)。

「手動依存性注入」 (ボブおじさん)も検討できます。

更新 3 - 2016 年 3 月

ここに別の例がありますが、Jeffrey はこれがデモ コードであることを明示しており、コメントは、これが Mark Seeman がコンポジション ルートと呼ぶもの(つまり、アプリケーションの起動時)で構成されることを示しています。

これは、Jeffrey の記事「Onion Architecture: Part 4 - After Four Years」で発見しました。

私のプロジェクトでは、多くのISerializers実装をアセンブリスキャナーに登録しています。FWIWこれは私の登録するコードですISerializers

その後、正しく登録されます

などなど。

現在、必要なシリアライザーを解決する方法を理解できた唯一の方法は、サービスロケーションコールをハードコーディングすることです。

クラスでjsonSerializerが特に必要であることがわかったので、ISerializerがプロパティ名に基づいて名前付きインスタンスを接続するように指示するルールなどを構成する方法はありますか？私が持つことができるように

そしてStructureMapはこのシナリオを正しく解決しますか？または、私はこれに間違ってアプローチしていますか？おそらく、ISerializerを実装する具体的なタイプを登録してから、具体的に使用する必要があります

具体的なクラスでこれらの線に沿った何かのために？

免責事項: DI とサービス ロケーター パターンの間には議論があることは承知しています。議論を避けるための質問があります。この質問は、たまたま Fowler のように「DI は... 理解するのが難しい... 全体として、必要な場合以外は避けたい」と考えているサービス ロケータ ファンへの質問です。私の質問の目的のために、私はDIを避ける必要があります（意図的に与えられていない理由）ので、私の質問に関係のない議論を引き起こしようとしているわけではありません.

質問: IOC コンテナーをシングルトンに保持することで発生する可能性のある唯一の問題 (上記の免責事項を思い出してください) は、子コンテナーの使用に関するものです。おそらく、子コンテナ自体はシングルトンではありません。最初は、それが本当の問題を引き起こしていると思いました。しかし、考えてみると、まさにそれが私が望む動作だと思い始めました (子コンテナーはシングルトンではなく、自由に Disposed() にすることができます)。

それから私の考えはさらに哲学的な領域に入りました。私はサービス ロケーターのファンなので、そもそも子コンテナーの概念がどれほど必要なのか疑問に思っています。私が有用性を確認した少数のケースでは、DI を満たすためであったか (とにかくほとんど避けています)、または IOC コンテナーに頼らずに問題を解決できました。私の考えは、「GetChildContainer」メソッドをリストすることさえ気にしないIServiceLocator インターフェイスに部分的に触発されました。

ですから、私の質問は次のとおりです。もしあなたがサービス ロケーターのファンなら、通常、子コンテナーは意味がないことに気づきましたか? それ以外の場合、それらはいつ不可欠になりましたか?

追加のクレジット: シングルトンのサービス ロケーターに他の哲学的な問題がある場合 (DI 支持者によって提起された問題は別として)、それらは何ですか?

とTから継承するダースのタイプを言いました。私は一般的な次のインターフェイスを持っていますEntityObjectIDataObject

データマネージャーの基本クラスもあります

そして私は特定のクラスを持っています

IDataManager<T>のインスタンスを返すサービスロケーターを実装したいT

しかし、私は多くのキャストなしでそれをきちんと実装する方法に固執しました。

何か案は？

更新：以前のサービスロケーターでそれらを登録するためのタイプを検出するために、次のコードを使用していました：

ジェネリックでのリフレクションがよくわからないようです

このシナリオを考えてみましょう。ログに書き込む必要があるビジネス ロジックがいくつかあります。

ILogger インターフェイスはどのように取得しますか? 主な可能性は 2 つあります。

1. コンストラクターで依存性注入を使用して渡します。
2. シングルトン Service Locator を介して取得します。

あなたはどちらの方法を好みますか、またその理由は何ですか? それとももっと良いパターンがありますか？

更新: すべてのメソッド呼び出しをログに記録する必要はないことに注意してください。メソッド内で発生する可能性がある、または発生しない可能性があるいくつかの (まれな) イベントのみをログに記録したいと考えています。

J2EE アプリケーションでは、weblogic で EJB2 を使用しています。

初期コンテキストの構築と EJB ホーム インターフェースの検索で時間を無駄にしないようにするために、Service Locator Patternを検討しています。

しかし、Web でいくつか検索した結果、InitialContext キャッシングにはこのパターンが推奨されることが多いにもかかわらず、EJB ホーム キャッシングについては否定的な意見があることがわかりました。

質問:

• EJB ホーム検索結果をキャッシュしても安全ですか?
• クラスタ ノードの 1 つが動作しなくなったらどうなりますか?
• サービス ロケーターのキャッシュを更新せずに新しいバージョンの EJB をインストールするとどうなりますか?

何らかのコンテキスト(NH の ISession、IRepository など) にアクセスする必要がある POCO オブジェクトに対して検証を実行する最善の方法について、何度も何度も考えています。

まだ確認できる唯一のオプションはService Locatorを使用することなので、検証は次のようになります。

私はすでにInversion Of Control と Dependency Injectionを使用していますが、多くの事実のために ServiceLocator が本当に好きではありません:

• 暗黙の依存関係を維持するのが難しくなります。
• コードのテストが難しくなります。
• 潜在的なスレッドの問題。
• ServiceLocator のみへの明示的な依存関係。
• コードがわかりにくくなります。
• テスト中に ServiceLocator インターフェイスを登録する必要があります。

しかし一方で、単純な POCO オブジェクトでは、ServiceLocator を使用せずに IoC/DI のみを使用して上記のような検証を実行する方法は他にありません。

現在、私はサービス層でそのような種類の検証を行っています。そのため、アクターがユーザー名を変更しようとするたびに (もちろん別のものかもしれません)、サービスはこの検証を実行します。明らかな欠点の 1 つは、User を使用するすべてのサービスがこのチェックを実行する必要があることです (1 回の呼び出しであっても)。

質問は次のとおりです。上記の状況で DI/IoC を使用する方法はありますか?

ありがとう、
ドミトリー。