タグ付けされた質問 「ioc-containers」

クラス内で依存関係を直接インスタンス化することは悪い習慣と見なされることを理解しています。これは、すべてを密接に結合するため、テストが非常に困難になるため、理にかなっています。 私が出くわしたほとんどすべてのフレームワークは、サービスロケーターの使用よりもコンテナーでの依存性注入を好むようです。どちらも、クラスが依存関係を必要とするときに返されるオブジェクトをプログラマーが指定できるようにすることで、同じことを達成しているようです。 2つの違いは何ですか？なぜ私は一方をもう一方よりも選ぶのでしょうか？

107 dependency-injection  ioc-containers  service-locator 

単語invertor controlは、私が見た定義で制御の反転を定義するためにまったく使用されていません。 定義 ウィキペディア 制御の反転（IoC）は、オブジェクト指向プログラミングの観点からここで表現されるプログラミング手法です。オブジェクト結合は、実行時にアセンブラオブジェクトによってバインドされ、通常、静的解析を使用したコンパイル時には不明です。〜http://en.wikipedia.org/wiki/Inversion_of_control マーティン・ファウラー Inversion of Controlは、Javaコミュニティの一般的なパターンであり、軽量コンテナをワイヤリングしたり、さまざまなプロジェクトのコンポーネントを凝集したアプリケーションに組み立てたりするのに役立ちます。〜に基づいて http://www.martinfowler.com/articles/injection.html （言い換え） それでは、Inversion of ControlがInversion of Controlと呼ばれるのはなぜですか？どのような制御が逆にされており、何によって？反転と制御という用語を使用して、制御の反転を定義する方法はありますか？

98 naming  definition  ioc-containers  inversion-of-control 

Dependency InjectionとInversion of Controlコンテナを使用すると、コードから" "キーワードがすべて削除さnewれますか？ 言い換えれば、どのオブジェクト/依存関係も、どれほど単純または短命であっても、IoCコンテナー内に「登録」し、それらを使用する必要があるメソッド/クラスに注入する必要がありますか？ いいえの場合、依存関係/オブジェクトがIoCコンテナに登録される線と、具体的な参照として「インライン」で作成されるものとの間に、newキーワードを介してどこで線を引きますか？

21 .net  dependency-injection  ioc-containers 

その人気にもかかわらず、依存性注入（および/またはDIコンテナーの使用）が、バグ数の削減、保守性の向上、または実際のソフトウェアプロジェクトの開発速度の向上に役立つことを示す経験的証拠はありますか？

18 design-patterns  dependency-injection  inversion-of-control  ioc-containers  evidence-based 

多くのプロジェクトで.NetにさまざまなIoCコンテナー（Castle.Windsor、Autofac、MEFなど）を使用しました。彼らは頻繁に虐待される傾向があり、多くの悪い慣行を助長していることがわかりました。 特にプラットフォーム/フレームワークを提供する場合、IoCコンテナーの使用に関する確立されたプラクティスはありますか？フレームワークライターとしての私の目標は、コードをできるだけシンプルで使いやすいものにすることです。オブジェクトを作成するために、10行または2行だけでなく、1行のコードを作成したいです。 たとえば、私が気づいたいくつかのコードの匂いがして、良い提案がありません： コンストラクターの多数のパラメーター（> 5）。サービスの作成は複雑になる傾向があります。すべての依存関係はコンストラクタを介して注入されます-コンポーネントがオプションであるということはめったにありませんが（テスト中を除く）。 プライベートクラスと内部クラスの欠如。これは、C＃とSilverlightの使用に関する特定の制限かもしれませんが、どのように解決されるのか興味があります。すべてのクラスがパブリックである場合、フレームワークインターフェイスが何であるかを伝えるのは困難です。それは私がおそらく触れるべきではないプライベートな部分にアクセスできるようにします。 オブジェクトのライフサイクルをIoCコンテナーに結合します。多くの場合、オブジェクトの作成に必要な依存関係を手動で構築することは困難です。オブジェクトのライフサイクルは、IoCフレームワークによって頻繁に管理されます。ほとんどのクラスがシングルトンとして登録されているプロジェクトを見てきました。明示的な制御が得られず、内部の管理も強制されます（上記の点に関連し、すべてのクラスはパブリックであり、それらを注入する必要があります）。 たとえば、.Netフレームワークには多くの静的メソッドがあります。DateTime.UtcNowなど。多くの場合、これが構築パラメーターとしてラップおよびインジェクトされるのを見てきました。 具体的な実装によっては、コードのテストが難しくなります。依存関係を挿入すると、コードが使いにくくなります-特にクラスに多くのパラメーターがある場合。 テスト可能なインターフェイスと使いやすいインターフェイスの両方を提供するにはどうすればよいですか？ベストプラクティスは何ですか？

18 .net  silverlight  dependency-injection  ioc-containers  inversion-of-control 

コードでIoCコンテナを使用することをお勧めします。動機は簡単です。次の依存性注入コードを取得します。 class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest( std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency) ) : d_(d) { } }; TEST(UnitUnderTest, Example) { std::auto_ptr<Dependency> dep(new MockDependency); UnitUnderTest uut(dep); //Test here } に： class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest() { d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency"))); } }; TEST(UnitUnderTest, Example) { UnitUnderTest uut; //Test here …

17 dependency-injection  inversion-of-control  ioc-containers 

これが質問のさらに別の繰り返しのように思える場合は申し訳ありませんが、トピックに関する記事を見つけるたびに、それは主にDIとは何かについて話します。だから、私はDIを取得しますが、誰もが入ろうとしているIoCコンテナの必要性を理解しようとしています。IoCコンテナのポイントは、依存関係の具体的な実装を単に「自動解決」することですか？私のクラスにはいくつかの依存関係がない傾向があるかもしれませんし、それが大したことではないのかもしれませんが、コンテナのユーティリティを正しく理解していることを確認したいです。 私は通常、ビジネスロジックを次のようなクラスに分類します。 public class SomeBusinessOperation { private readonly IDataRepository _repository; public SomeBusinessOperation(IDataRespository repository = null) { _repository = repository ?? new ConcreteRepository(); } public SomeType Run(SomeRequestType request) { // do work... var results = _repository.GetThings(request); return results; } } そのため、依存関係は1つだけであり、場合によっては2番目または3番目の依存関係がありますが、それほど頻繁ではありません。そのため、これを呼び出すものはすべて、それ自身のレポを渡すか、デフォルトのレポを使用することができます。 IoCコンテナに関する私の現在の理解に関する限り、コンテナが行うことはIDataRepositoryを解決することだけです。しかし、それがすべてである場合、依存関係が渡されないときに私の操作クラスがすでにフォールバックを定義しているため、大量の値が表示されていません。これは同じフォールバックリポジトリを使用します。レジストリ/工場/コンテナの1つの場所でそのリポジトリを変更できます。それは素晴らしいことですが、それはそれですか？

15 c#  dependency-injection  inversion-of-control  ioc-containers 

Google Guiceのような依存性注入フレームワークは、その使用（ソース）に次の動機を与えます。 オブジェクトを構築するには、まずその依存関係を構築します。しかし、各依存関係を構築するには、その依存関係などが必要です。したがって、オブジェクトを作成するときは、オブジェクトグラフを作成する必要があります。 手作業でオブジェクトグラフを作成するのは手間がかかり（...）、テストが困難になります。 しかし、私はこの議論を買いません。依存性注入フレームワークがなくても、インスタンス化が簡単で、テストが便利なクラスを作成できます。たとえば、Guiceの動機付けページの例を次のように書き換えることができます。 class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = transactionLog; } // constructor for production, calling the (productive) constructors of the collaborators public BillingService() …

13 design-patterns  object-oriented  dependency-injection  ioc-containers 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 依存性注入をC＃のような言語に直接統合する方法を少し考えてきました。私はあなたの意見を聞きたいと思う潜在的な解決策を考え出しました。私は多くの依存関係注入フレームワークを使用していないので、見落としているものがあるかもしれません とにかく、キーワードを使用してプロパティを「注入可能」として宣言できるようにするという考えです。オブジェクトがインスタンス化され、そのプロパティがコンストラクターまたはオブジェクト初期化子を介して初期化されない場合、オブジェクトはいくつかのグローバルサービスからそのプロパティタイプのインスタンスを要求します。 同様に、さまざまなタイプのハンドラーをそのサービスに登録して、注入されたプロパティタイプをインスタンス化できるようにします。 この種のアーキテクチャーIMOを使用する利点は、かなり柔軟で使いやすいことです。欠点は、インジェクションを持つクラスを開始するたびにシングルトンへのコールアウトを実行するオーバーヘッドがある可能性があることです。 繰り返しになりますが、これは、高性能ソリューションで頻繁にインスタンス化されるクラスの問題にすぎないため、それほど問題にはなりません。おそらく、それらのインスタンスで何らかのファクトリを使用できます。 考え、問題、質問、より良いアイデア？ コード public class SomeClass { public SomeClass() { //implicit behavior if Animal is not set in constructor or initializer this.Animal = GlobalInjector.Get(this,typeof(Mammal)) } public injectable Mammal Animal { get; set; } } GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

10 programming-languages  dependency-injection  ioc-containers 

ソフトウェアの構成にDIC / IoCレジストリを使用するタイミングと、ファクトリを使用するタイミング、およびどちらのアプローチの背後にある理由も理解しようとしています。 レジストリを使用して簡単に構成できるDIコンテナー（DIC）としてStructureMapを使用しています。DICでは、実質的にすべての登録済みオブジェクトは静的です。つまり、DICが構成され、DICでシングルトンとして構成されたら、実行時に実装/インスタンスを変更/交換する必要はありません。ただし、ソフトウェア（SW）はさまざまなデバイスで実行されるため、ハードウェアを適切に構成するには、ソフトウェアが実行されるデバイスに応じてデバイス固有のレジストリを選択する必要があります。 一部のオブジェクトの構築には構成ファイルの読み取りが必要なため、構成の読み取りとオブジェクトの作成を分離するために、ファクトリを使用してこれらのインスタンスをDICに返しています。対応するプラグインタイプのファクトリゲッターをDICに登録しました。 IMotor具象型Motor1とを備えたプラグイン型があるとしましょうMotor2。これはファクトリで処理する必要があります。デバイスの構成方法を決定する方法は2つあります。 私はSWが上に実行されていることをデバイスに関する情報を渡しMotorFactory、それが正しいモータを返す、のいずれかMotor1、またはMotor2。この場合、決定のロジックはファクトリー内にあります。 DICを実行しているデバイスに応じてDICを構成し、2つのファクトリMotor1Factoryを作成します。1 Motor2Factoryつは作成Motor1し、もう 1つは作成しますMotor2。この場合IMotor、Motor1Factoryまたはのいずれかを使用するデバイス固有のレジストリに、異なるレジストリエントリが含まれますMotor2Factory。 今私の質問です：これらの2つの方法のどちらが望ましいのですか？私には、コードベース全体でどのタイプをインスタンス化するかを決定するロジックを広げているため、最初のケースは単純ではなく複雑です。一方、2番目のケースでは、コード内のファクトリの数を効果的に増やしています。これは、（ほとんど）各具象型のファクトリが必要になるためです。抽象ファクトリーがミックスに追加されると、さらに混乱します。 繰り返しますが、どちらの方法を使用すればよいですか？さらに重要なのは、どちらの方法に進むかを決定するための優れた指標は何ですか？

9 configuration  factory  ioc-containers 

Mark Seemannの 'Ploeh'ブログを含むいくつかのソースで、IoCコンテナーのコンポジションルートの適切な配置がアプリケーションのエントリポイントに可能な限り近いことについて読んだことがあります。 .NETの世界では、これらのアプリケーションは、一般的にWebプロジェクト、WPFプロジェクト、コンソールアプリケーション、一般的なUIを持つもの（読み取り：ライブラリプロジェクトではない）と考えられているようです。 構成ルートをライブラリプロジェクトのグループの論理的なエントリポイントを表し、このようなプロジェクトグループのクライアントが他の誰かの作業である場合、構成ルートをライブラリプロジェクトのエントリポイントに配置することは、この賢明なアドバイスに本当に反していますか？ 、その作者が自分のプロジェクト（UIプロジェクトまたはさらに別のライブラリプロジェクトでさえ）にコンポジションルートを追加できない、または追加しないだろう？ 私はIoCコンテナー実装としてNinjectに精通していますが、必要なすべてのバインディング構成を含むモジュールをスキャンできるという点で、他の多くも同じように機能すると思います。これは、バインディングモジュールを独自のライブラリプロジェクトに配置して、メインライブラリプロジェクトの出力でコンパイルできることを意味します。クライアントが構成を変更したい場合（私のケースではありえないシナリオ）、置換DLLをドロップして、バインディングモジュールを含むライブラリ。 これにより、最も一般的なクライアントが依存関係の注入とコンポジションのルートを処理する必要がなくなり、ライブラリプロジェクトグループのAPIが最もクリーンになります。 しかし、これはこの問題に関する従来の知恵に直面して飛んでいるようです。そこにあるほとんどのアドバイスは、開発者が自分のケースではなく、UIプロジェクトの開発にも何らかの調整を行っていることを前提としているだけですか？

8 design-patterns  .net  dependency-injection  architectural-patterns  ioc-containers 

ガベージコレクションされたフレームワークを前提として、IOCコンテナーを使用して純粋にステートレスなサービスを注入する場合、コンテナーの単一インスタンスのライフスパンを使用するか、使用するたびにオブジェクトを再作成し、オブジェクトとそのすべての依存関係を破棄する方が一般的です使い終わったらすぐに？

8 ioc-containers