問題タブ [service-locator]

パブリック型のコレクションを消費者に提供するライブラリを作成しています。

このライブラリの依存性注入に適した型を作成したいと考えています。つまり、すべてのクラスには、初期化されるオブジェクトのすべての依存関係を指定できるコンストラクターが必要です。また、ライブラリが構成よりも規則に従うことも望んでいます。これは、消費者がデフォルトの動作を望む場合、パラメーターなしのコンストラクターを使用することができ、オブジェクトは何らかの方法でそれ自体の依存関係を構築することを意味します。

例 (C#):

私の最初の解決策は、サービス ロケーター パターンを使用することです。

コードは次のようになります。

しかし、これには問題があります。Service locator はアンチパターン (リンク) としてフラグが立てられており、私はこれらの議論に完全に同意します。一方、Martin Fowler は、まさにこの状況 (ライブラリ プロジェクト) でサービス ロケーター パターンを使用することを提唱しています (リンク)。サービスロケーターが本当に悪い考えであることが判明した後、ライブラリを書き直す必要がないように注意したいと思います。

結論として、このシナリオではサービスロケータは問題ないと思いますか? まったく別の方法で問題を解決する必要がありますか? どんな考えでも大歓迎です...

私はしばらくの間プログラミングを行ってきましたが、それぞれの概念が何を意味するのかを理論的に知ることに興味はありませんでした.さまざまなプログラミング概念を使用しているかもしれませんが、それを知りません.

Service Locator : 私にとっては、コード量を減らして開発をスピードアップするためのショートカットの記録を指します。1 つの質問は、ロケーターが名前空間/クラスのみを参照できるか、それとも変数のレジストリを持つことができるかということです。

これが私の理解です：

依存性注入 (および依存性注入コンテナー) : オブジェクト内にオブジェクトを注入し、ファクトリ パターンに関係なく、これらへのアクセスを高速化します。そしてDIコンテナ？

これが私の理解です：

制御の反転: このデザイン パターンを理解していない (または、理解しているが、IoC を行っているかどうかがわからない)

それでは、理論的に (できれば簡単な例を使用して)、これらの概念のそれぞれは何を意味するのでしょうか? 私は正しいですか、または何が間違っていますか/改善できますか?

ありがとう！

これは、コンストラクタインジェクションを使用してServiceLocatorパターンを回避する正しい方法ですか？

避けたいServiceLocatorを使用したクラスの消費。

MEFを使用したソリューション。上記を変更*EntitySomething'sto Export、および

実際にはまだ試していませんが、これを達成する他の方法はどこにあるのだろうかと考えていました。

ありがとう

Caliburn.MicroとNinjectを使用したMVVMに基づくWPFアプリケーションがあります。ShellViewModelというルートビューモデルがあります。CaliburnのBootstrapperで構成されているいくつかの依存関係（コンストラクターを介して注入）があります。ここまでは順調ですね。

どこかに、いくつかのボタンを備えたMenuViewModelがあり、それらは独自の依存関係を持つ他のビューモデルを開きます。これらのビューモデルはルートオブジェクトの作成中には作成されませんが、IoCコンテナから依存関係を注入したいと思います。

サービスロケーターと依存性注入に関するこの質問を読み、指摘されている点を理解しています。

ただし、動的に作成されているビューモデルを適切に挿入するには、MenuViewModelがIoCコンテナにアクセスできる必要があるという印象を受けています。これは避けようとしていることです。別の方法はありますか？

最近、DI、SL アンチパターン、AOP など、アプリケーションの設計パターンに関する多くの記事を読んでいました。この理由 - 私は設計の妥協点を見つけたいと思っています: 疎結合で、クリーンで、使いやすいです。DI は、コンストラクターまたはプロパティの汚染につながるクロスカッティングとオプションの依存関係という 1 つの問題を除いて、ほぼ解決策のようです。だから私はこれに対する私自身の解決策を持ってきて、あなたがそれについてどう思うか知りたい.

マーク シーマン (DI 本の著者であり、有名な「SL はアンチ パターン」という声明の著者) は、その本の中で、アンビエント コンテキストと呼ばれるパターンについて言及しています。あまり好きではないと彼は言いますが、このパターンは依然として興味深いものです。スコープがあり、デフォルト値を提供するため、null をチェックする必要がないことを除けば、古き良きシングルトンのようなものです。それには 1 つの欠陥があります - それはありませんし、そのスコープと自分自身を処分する方法について知ることができません。

では、ここで Service Locator を適用してみませんか? Ambient Context オブジェクトのスコーピングと破棄の両方の問題を解決できます。アンチパターンだと言う前に: コントラクトを隠すときです。しかし、私たちの場合、OPTIONAL コントラクトを非表示にしているので、IMO はそれほど悪くありません。

ここに私が何を意味するかを示すいくつかのコードがあります:

編集：具体的な質問をしないことは、スタックオーバーフローの設計と矛盾することを認識しています。したがって、この設計が悪い理由を最もよく説明している投稿を回答としてマークし、より良い解決策（または追加？）を提供します。しかし、AOP を提案しないでください。それは良いことですが、コード内で本当に何かをしたい場合には解決策ではありません。

編集 2: ServiceLocator.Current is null のチェックを追加しました。SL が構成されていない場合に既定の設定で動作するようにすることが、私のコードで意図していることです。

UnityContainer でフォローする方法がわかりません。

ServiceLocator.ResolveAll<X>両方のインスタンスを返すように、両方の具象クラスを登録する必要があります。同じ時間Resolve<A>でResolve<B>、同様に機能するはずです。さらに、サービスの登録中に自分でインスタンス化してはいけません。

名前付き登録を使用して機能XさせるResolveAllと、各具象クラスの 2 つのインスタンスが作成されます。すべてのインターフェイスに名前付き登録を使用すると、機能Resolve<A>しResolve<B>ません。このアプローチを使用すると、ResolveAll何も返されません。

UnityContainer でトリックを行うには?

CaliburnMicroとnHibernateを利用した新しいLOBMVVMプロジェクトのアーキテクチャを設計しようとしていますが、現在、DIとIOCを調査しています。

Caliburn Microをブートストラップするための多くの例では、DI\IOCメカニズムとしてMEFを使用しています。

私が苦労しているのは、MEFはかなり人気があるように見えますが、Mef [Imports]アノテーションのアイデアは、サービスロケーターの別のフレーバーのように私にはにおいがしますか？

私が見たほとんどすべての例がMEFを正しく使用していないという点で、MEFについて何かが足りないのでしょうか、それとも、サービスロケーターの問題全体を回避するために、MEFがどのように使用されているのかを完全に理解していないのでしょうか。

しばらく前に同様の質問がありましたが、IoC / DIのトピック全体と、私が達成しようとしていたことについての理解がはるかに少ないので、ここでもう一度説明します。

社内で一般的に使用するライブラリを構築しています。パブリックAPIの最も一般的に使用される部分は、すでにIoCに対応していますが、下位レベルの領域では、まだかなりの新機能が進行中であり、これを削除したいと思います（ただし、現時点では、実際よりも正式な理由でより多く使用されています）必要性）。

これ自体は簡単に実行できますが、もちろん、ライブラリを使用するたびに、すべてのコンポーネントを再度配線する必要があります。これはほとんど常に同じように見えるので、私は通常、これらのデフォルトの登録をAutofacモジュールにラップして、それで完了します。

（質問1：このモジュールはメインライブラリアセンブリに含まれるのでしょうか、それともAutofacがライブラリで使用される唯一のIoCコンテナである可能性が高い場合でも、スタンドアロンパッケージである必要がありますか？）

問題は、私が現在、IoCの目的を実際に理解している、またはIoCコンテナがどのように使用されているかは言うまでもなく、IoCコンテナが何をするのかを知っている唯一の開発者であるということです。そして、他のすべての人にそれらを伝えるのは悪い考えです。 Autofacパッケージを使用するか、貧乏人のDIを使用して12以上のオブジェクトのグラフを手動で作成することができます。（私はみんなを知っています-私はとにかく私の多くの小さなクラスすべてに夢中なので、彼らはそれを放っておいて、彼らが必要なものを自分で構築するでしょう。）

これを解決するために私が考えたのは、一般的に必要なタイプ（Autofacモジュールによって配線されたものと同じように見える）の事前構成されたオブジェクトをプルするService Locatorのようなものを追加することです。おそらく、軽量のIoCコンテナーによって内部的に配線されます。 。

Service Locatorはアンチパターンであり、どのような問題が発生するかを知っています。これをオブジェクト構成の（私の）手段として使用することは決してありませんが、IoC/SOLID障害の「ショートカット」としては実行可能でしょうか。 ？他にどのようなオプションがありますか？その場合、ライブラリにAutofacモジュールを含めて、「サービスロケーター」をそのフロントエンドとして機能させることも意味がありますか？

orまたはそのようなものBaseFormに依存するがあるとします。現在、アンチパターンであることがわかっているサービスロケーターを使用して、必要なサービスの正しい実装を解決しています。ILoggerIResourceManager

• この種の依存関係を解決するには、コンストラクター注入を使用するのが正しい方法ですか?
• 依存関係が解決されたインスタンスを作成するために、自分のBaseForm(およびその派生型) をコンテナーに登録する必要がありますか? それはすべてを複雑にしませんか？
• サービス ロケータをラップする静的ファクトリを使用するのは悪いことですか?
• 単体テストはさておき、サービスロケーターのアンチパターンを使用したために本当に罰せられるのでしょうか?

一度にたくさん質問してすみません。私は次のSOの質問と他の多くの質問を読みましたが、それらを読んでも混乱が増すだけでした:

• Service Locator ではなく Dependency Injection を使用する方法
• 依存性注入パターンとサービス ロケーター パターンの違いは何ですか?
• Service Locator アンチパターンを回避するには?

大規模なソリューション (> 100 プロジェクト) があり、ほぼすべてのタイプがインスタンス化のためにサービス ロケーター (例 1) または独自のタイプ ディクショナリ (例 2) のいずれかを使用します。

たとえば、次のようなものがあります。

また

2 番目の例では、構成ファイルに移動して、リフレクションを使用してインスタンス化する具体的なオブジェクトを見つけます。

コードをたどる場合、どの具象型が使用されているかが明確でないため、作業がより困難になります。そのため、コードの一部を学習しようとするときに、マッピングを何度も確認する必要があります。上記を例として使用すると、F12 on:quote.DoSomething()を押すと、インターフェース定義に移動します。

また、実装が少し難しくなります。代替手段が 1 つのクラスだけの場合、インターフェイス + 具象クラス + 構成マッピングが必要です。

考えてみると、何かが別の型に「交換」されたことはありません。したがって、IoC を実装しましたが、それを使用していないか、少なくともほとんど使用していません。

それで-それは実際に価値がありますか？実装が間違っていたり、やりすぎたりしていませんか? 私は何か誤解していますか？