タグ付けされた質問 「inversion-of-control」

私は依存性注入（DI）と制御の反転（IOC）の多くの参照を見てきましたが、それらの間に違いがあるかどうかは本当にわかりません。 どちらかまたは両方を使い始めたいのですが、それらの違いについて少し混乱しています。

117 dependency-injection  inversion-of-control 

単語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 

新しいシステムを設計していますが、制御の反転（IOC）とは何か、さらに重要なこととして、それをいつ使用するかを知りたいです。 インターフェイスで実装する必要がありますか、それともクラスで実行できますか？

64 design  design-patterns  inversion-of-control 

私は、チームリーダーがSOLID開発原則の熱心な支持者であるチームに取り組んでいます。しかし、彼は複雑なソフトウェアをドアから取り出すのに多くの経験を欠いています。 すでに非常に複雑なコードベースであったものにSRPを適用した状況があり、現在では非常に断片化されており、理解とデバッグが困難になっています。 現在、コードの断片化だけでなく、プライベートまたは保護されている可能性のあるクラス内のメソッドが「変更の理由」を表すと判断され、パブリックまたは内部クラスおよびインターフェースに抽出されているため、カプセル化にも問題がありますアプリケーションのカプセル化の目標に沿っていない。 20を超えるインターフェイスパラメーターを受け取るクラスコンストラクターがいくつかあるため、IoCの登録と解決はそれ自体が怪物になりつつあります。 これらの問題のいくつかを修正するために使用できる「SRPからのリファクタリング」アプローチがあるかどうかを知りたいです。私は、いくつかの密接に関連するクラスを「ラップ」してそれらの機能の合計への単一のアクセスポイントを提供する多数の空の粗いクラスを作成する場合、SOLIDに違反しないことを読んだ過度にSRPされたクラスの実装）。 それとは別に、誰もが幸せなまま、開発努力を実践的に続けることを可能にする解決策は考えられません。 助言がありますか ？

57 c#  wpf  inversion-of-control  single-responsibility 

IOCコンテナの目的は何ですか？組み合わされた理由は、次のように簡略化できます。 OOP / SOLID開発の原則を使用する場合、依存関係の注入が面倒になります。下位レベルの複数のレベルの依存関係を管理し、構築を通じて依存関係を再帰的に渡す最上位のエントリポイントがあるか、必要に応じて依存関係を構築するファクトリー/ビルダーパターンおよびインターフェイスにコードが多少重複しています。 これを実行するには、何のOOP / SOLID方法はありませんと、超きれいなコードを持っているが。 前のステートメントが正しい場合、IOCコンテナーはどのようにそれを行いますか？私の知る限り、それらは手動のDIでは実行できない未知の手法を使用していないため、IOCコンテナは静的オブジェクトのプライベートアクセッサを使用してOOP / SOLID原則を破ることだけです。 IOCコンテナは、背後で次の原則を破っていますか？私はよく理解しているので、これは本当の質問ですが、他の誰かがより良い理解を持っていると感じています スコープ制御。スコープは、コード設計に関するほとんどすべての決定の理由です。ブロック、ローカル、モジュール、静的/グローバル。スコープは、ブロックレベルでできるだけ多く、静的でできるだけ少なくする必要があります。宣言、インスタンス化、およびライフサイクルの終了が表示されます。言語とGCは、明示的に明示している限り、スコープを管理することを信頼しています。私の研究では、IOCコンテナがほとんどまたはすべての依存関係を静的として設定し、バックグラウンドでAOP実装を介して制御していることがわかりました。したがって、何も透明ではありません。 カプセル化。カプセル化の目的は何ですか？なぜプライベートメンバーを保持する必要があるのですか？実際的な理由により、APIの実装者は、状態（所有者クラスによって管理される必要があります）を変更して実装を中断することはできません。しかし、セキュリティ上の理由から、メンバー状態を追い越し、検証とクラス制御をバイパスするインジェクションが発生しないようにします。したがって、プライベートメンバーへの外部アクセスを許可するためにコンパイル時間の前に何らかの形でコードを挿入するもの（モックフレームワークまたはIOCフレームワーク）は非常に巨大です。 単一責任の原則。表面的には、IOCコンテナは物事をよりきれいにするようです。しかし、ヘルパーフレームワークなしで同じことを達成する方法を想像してください。十数個の依存関係を持つコンストラクターが渡されます。それはIOCコンテナーでそれをカバーすることを意味するものではありません、それは良いことです！コードをリファクタリングし、SRPに従うことを示すサインです。 オープン/クローズ。SRPがクラスのみではないように（メソッドはもちろん、SRPを単一の責任ラインに適用します）。Open / Closedは、クラスのコードを変更しないという単なる高レベルの理論ではありません。プログラムの構成を理解し、何が変更され、何が拡張されるかを制御する習慣です。IOCコンテナは、次の理由でクラスの動作方法を完全に変更できます。 a。主なコードは依存関係の切り替えを決定するのではなく、フレームワークの構成です。 b。スコープは、呼び出し元のメンバーによって制御されていないときに変更される可能性があり、代わりに静的フレームワークによって外部で決定されます。 したがって、クラスの構成は実際には閉じられていません。サードパーティのツールの構成に基づいて変更されます。 これが質問である理由は、私が必ずしもすべてのIOCコンテナのマスターではないからです。また、IOCコンテナーのアイデアは素晴らしいものの、実装が不十分なことを覆い隠す外観にすぎません。しかし、外部のスコープ制御、プライベートメンバーアクセス、および遅延読み込みを実現するには、多くの重要な疑問の余地のある作業を継続する必要があります。AOPは素晴らしいですが、IOC Containersを介して達成される方法にも疑問があります。 私は、C＃と.NET GCが期待どおりに動作することを信頼できます。しかし、コンパイルされたコードを変更して、手動で実行できないことに対する回避策を実行するサードパーティ製のツールに同じ信頼を置くことはできません。 EG：Entity Frameworkと他のORMは、厳密に型指定されたオブジェクトを作成してデータベースエンティティにマッピングし、CRUDを実行するための基本的な機能を提供します。誰でも独自のORMを構築し、OOP / SOLID原則を手動で従うことができます。しかし、これらのフレームワークは私たちを助けてくれるので、毎回車輪を再発明する必要はありません。一方、IOC Containersは、OOP / SOLID原則を意図的に回避し、それを隠すのに役立つようです。

51 object-oriented  solid  inversion-of-control 

Inversion of Controlの原則とDependency Injectionをその実装としてさらに読んでいますが、それを理解していると確信しています。 基本的に「クラス内でクラスメンバーのインスタンス化を宣言しない」と言っているようです。むしろ、インスタンス化はコンストラクターに渡され、コンストラクターを通じて割り当てられる必要があります。外部ソースからクラスに「注入」されました。 それがそうであるように思えるこの単純な場合、注釈を使用してこれを実装するspringやguiceのようなフレームワークが必要なのはなぜですか？ここに基本的なものがありませんか？Dependency Injectionフレームワークの使用方法を理解するのに本当に苦労しています。 編集：可能性のある重複について、私の質問はSpringだけでなく一般的なDIフレームワークについて尋ねているため、よりユニークだと思います。Springは単なるDIフレームワークではないため、DIに関係のないSpringを使用したい理由はたくさんあります。

42 dependency-injection  spring  inversion-of-control  google-guice 

比較的大きなアプリケーションに依存性注入を実装したいと考えていますが、経験はありません。私は、UnityやNinjectなどのIoCの概念といくつかの実装、および利用可能な依存関係インジェクターを研究しました。しかし、私を避けているものが1つあります。アプリケーションでインスタンス作成を整理するにはどうすればよいですか？ 私が考えているのは、いくつかの特定のクラスタイプのオブジェクトを作成するロジックを含むいくつかの特定のファクトリを作成できるということです。基本的に、このクラスの静的カーネルインスタンスのNinject Get（）メソッドを呼び出すメソッドを持つ静的クラス。 アプリケーションに依存性注入を実装する正しいアプローチでしょうか、それとも他の原則に従って実装する必要がありますか？

22 c#  .net  dependency-injection  inversion-of-control  ninject 

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

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

私はDI / IOCの大ファンです。ハードな依存関係の処理/抽象化に最適であり、作業が少し楽になります。 しかし、私はそれについて少し不満があり、それを解決する方法がわかりません。 DI / IOCの基本的な考え方は、オブジェクトがインスタンス化されると、その依存関係はすべてコンストラクター内で事前に入力されるということです。 ただし、IMHOには、コンストラクター用のパラメーターのタイプがいくつかあります（特にオブジェクトが不変の場合）。 依存関係（オブジェクトが機能するために必要なオブジェクト） 構成（作業を行うために必要な環境に関する情報） パラメーター（作業が行われるデータ） IOCは依存関係でうまく機能することがわかりました。しかし、私はまだ他の2つに対処する最善の方法を考えています。ただし、コンストラクターはIOCコンテナーによって実行されるように実行されるため、これらのアイテムをIOCコンテナーに配置する必要があるようです。 人々が採用している戦略/パターンと、人々が発見した利点と欠点を知りたい。 NB。これは非常に主観的な質問であることを認識しており、SEガイドラインに従って「良い」主観的な質問にしようとしました。

18 design-patterns  configuration-management  inversion-of-control 

多くのプロジェクトで.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 

私は最近、より「組織化された」プログラミングを掘り下げてきましたが、実装ではなくインターフェイスにプログラミングする必要があることを学んでいます。それを念頭に置いて、可能であれば実装を記述する前に、インターフェイスでプロジェクトを「スケッチ」する方が良いでしょうか？ サードパーティのライブラリ（Lidgrenなど）を使用する場合は、これらをインターフェイスでラップし、IOCコンテナを介して解決する必要がありますか、それともインターフェイスに公開してもかまいませんか？

14 c#  design  interfaces  third-party-libraries  inversion-of-control 

テスト駆動開発（TDD）、依存性注入（DI）、および制御の反転（IoC）をすべて同時に行うことを学びました。TDDを使用してコードを記述するとき、クラスのコンストラクターで常にDIを使用します。これは、TDDをどのように学んだかによるものなのか、それともTDDの自然な副作用なのか疑問に思っています。 だから私の質問は次のとおりです：TDDプリンシパルに従って、外部サービスに依存しない単体テストを書くことは必然的にDIにつながりますか？

14 tdd  dependency-injection  inversion-of-control 

過去1年で、Dependency InjectionとIOCコンテナを使用して新しいシステムを作成しました。これは私にDIについて多くを教えてくれました！ ただし、概念と適切なパターンを学んだ後でも、コードを分離し、IOCコンテナーをレガシーアプリケーションに導入することは難しいと考えています。アプリケーションは、真の実装が圧倒されるほどの大きさです。値が理解され、時間が与えられたとしても。こんなことをする時間を与えられたのは誰ですか?? もちろん、単体テストをビジネスロジックに組み込むことが目標です！ テスト防止のデータベース呼び出しと絡み合っているビジネスロジック。 この記事を読みましたが、このLos Techiesの記事で説明されているように、Poor Man's Dependency Injectionの危険性を理解しています。私はそれが本当に何も切り離さないことを理解しています。 実装には新しい依存関係が必要になるため、システム全体で多くのリファクタリングが必要になることを理解しています。どんなサイズの新しいプロジェクトでも使用することは考えません。 質問： Poor ManのDIを使用して、レガシーアプリケーションにテスト容易性を導入し、ボールローリングを開始しても大丈夫ですか？ さらに、Poor ManのDIを真のDependency Injectionへの草の根アプローチとして使用することは、原則の必要性と利点を教育する価値のある方法ですか？ インターフェイスの背後でデータベース呼び出しの依存関係と抽象化を呼び出すメソッドをリファクタリングできますか？単純に抽象化することで、そのメソッドをテスト可能にします。これは、コンストラクターのオーバーロードを介してモック実装を渡すことができるためです。 今後、支援が得られると、プロジェクトを更新してIOCコンテナを実装し、抽象化を取り入れるコンストラクタを公開することができます。

14 architecture  dependency-injection  legacy  inversion-of-control