タグ付けされた質問 「dependency-injection」

違いは何ですかService、ProviderとFactoryAngularJSには？

3319 angularjs  dependency-injection  angularjs-service  angularjs-factory  angularjs-provider 

依存関係注入についての特定の質問がすでに投稿されている質問がいくつかあります。たとえば、いつ使用するか、どのフレームワークがあるかなどです。しかしながら、 依存性注入とは何ですか？いつ/なぜ使用する必要があるのですか？

3075 design-patterns  language-agnostic  dependency-injection  terminology 

私はSpringSourceのいくつかのブログを調べています。そのうちの1つのブログでは、著者が使用して@Injectおり、彼もを使用できると思います@Autowired。 これがコードの一部です： @Inject private CustomerOrderService customerOrderService; 私は違いではないと確信している@Injectと@Autowired、誰かがその違いを説明している場合、それを感謝し、どちらがどのような状況の下で使用しますか？

695 java  spring  dependency-injection  autowired  inject 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 私はしばらくの間、依存性注入（DI）を使用しており、コンストラクター、プロパティ、またはメソッドのいずれかに注入しています。制御の反転（IoC）コンテナーを使用する必要性を感じたことはありません。ただし、読むほど、コミュニティからIoCコンテナを使用するようにというプレッシャーが強くなります。 StructureMap、NInject、Unity、Funqなどの.NETコンテナで遊んだ。IoCコンテナーがコードにどのように利益をもたらすか、または改善するかはまだわかりません。 また、同僚の多くが理解できないコードを目にするため、職場でコンテナを使い始めるのも怖いです。彼らの多くは新しい技術を学ぶことに消極的かもしれません。 IoCコンテナを使用する必要があることを納得してください。職場で他の開発者と話すとき、これらの引数を使用します。

598 dependency-injection  inversion-of-control  ioc-container 

依存性注入（DI）を理解しようとしていますが、もう一度失敗しました。ばかげているように見えるだけです。私のコードは決して混乱しない。私はほとんど仮想関数とインターフェイスを作成しません（ただし、ブルームーンで1回行います）。すべての構成は、json.netを使用して（時にはXMLシリアライザーを使用して）魔法のようにクラスにシリアル化されます。 それがどのような問題を解決するのかよくわかりません。「こんにちは。この関数を実行すると、このタイプのオブジェクトを返し、これらのパラメーター/データを使用します。」 しかし...なぜそれを使うのでしょうか？私も使用する必要がなかったことに注意してくださいobjectが、それが何のためにあるのか理解しています。 DIを使用するWebサイトまたはデスクトップアプリケーションを構築する場合の実際の状況は何ですか？ゲームでインターフェイス/仮想関数を使用する理由を簡単に考え出すことができますが、ゲーム以外のコードでそれを使用することは非常にまれです（単一のインスタンスを思い出せないほどまれです）。

536 dependency-injection 

Martin Fowlerが書いた論文によると、制御の逆転はプログラムの制御フローが逆転する原理です。プログラマーがプログラムのフローを制御する代わりに、外部ソース（フレームワーク、サービス、その他のコンポーネント）が制御を行いますそれ。何かを別のものに差し込むようなものです。彼はEJB 2.0についての例を述べました： たとえば、セッションBeanインターフェースは、ejbRemove、ejbPassivate（セカンダリストレージに保存）、およびejbActivate（パッシブ状態から復元）を定義します。これらのメソッドがいつ呼び出されるかを制御するのではなく、何を実行するかを制御します。コンテナは私たちを呼びます、私たちはそれを呼びません。 これは、フレームワークとライブラリの違いにつながります。 制御の反転は、フレームワークをライブラリと異なるものにする重要な部分です。ライブラリは基本的に、呼び出すことができる関数のセットであり、最近では通常、クラスに編成されています。各呼び出しはいくつかの作業を行い、クライアントに制御を返します。 私は、DIがIOCであるという視点は、オブジェクトの依存関係が逆転することを意味します。オブジェクト自体の依存関係、ライフサイクルを制御する代わりに、何か他のことがあなたのために行います。ただし、DIについて手作業で説明したように、DIは必ずしもIOCではありません。それでもDIはあり、IOCはありません。 ただし、このペーパー（pococapsule、C / C ++の別のIOCフレームワークから）では、IOCとDIがあるため、IOCコンテナーとDIフレームワークはJ2EEよりはるかに優れていることを示唆しています。 、したがって、それをプレーン・オールドJava / C ++オブジェクト（POJO / POCO）にしません。 依存性注入パターン以外のコントロールコンテナーの反転（アーカイブリンク） 古いコンポーネントベースの開発フレームワークの何が問題であるかを理解するための追加の読み物。これは上記の2番目のペーパーにつながります。制御の反転の理由と内容（アーカイブリンク） 私の質問：IOCおよびDIとは正確には何ですか？私は混乱しています。pococapsuleに基づいて、IOCはオブジェクトまたはプログラマーとフレームワーク間のコントロールの単なる反転よりも重要なものです。

525 dependency-injection  inversion-of-control 

Dependency Injectionの使用法として引用されている例のほとんどは、ファクトリーパターンを使用して解決することもできます。依存関係の注入とファクトリーの違いは、使用法/設計に関してはぼやけている、または薄いようです。 誰かが私にあなたがそれをどのように使うかが違いをもたらすと私に言ったら！ 私はかつて、StructureMapのDIコンテナを使用して問題を解決しました。その後、シンプルなファクトリで機能するように再設計し、StructureMapへの参照を削除しました。 それらの違いと何をどこで使用するのか、ここでのベストプラクティスは何ですか？

498 dependency-injection  factory-pattern  design-patterns 

Entity Frameworkの設定方法を説明する記事をたくさん読んでいます DbContextて、さまざまなDIフレームワークを使用するHTTP Webリクエストごとに1つだけが作成および使用されるます。 そもそもなぜこれが良いアイデアなのでしょうか？このアプローチを使用すると、どのような利点がありますか？これが良い考えとなる特定の状況はありますか？この手法を使用して、DbContextリポジトリメソッドの呼び出しごとにをインスタンス化するときに実行できないことはありますか？

398 c#  asp.net  entity-framework  dependency-injection  dbcontext 

現在のところ、この質問はQ＆A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 どのC＃/。NET依存性注入フレームワークを調査する価値がありますか？そして、あなたはそれらの複雑さとスピードについて何と言えますか？

386 c#  .net  dependency-injection  inversion-of-control 

@Resource（jsr250）または@Autowired（Spring固有）のどのアノテーションをDIで使用する必要がありますか？ 私は過去に両方をうまく使用したことが@Resource(name="blah")あり、@Autowired @Qualifier("blah") @Resourcejsrの人々によって承認されているので、私の本能はタグを守ることです。 誰もがこれについて強い考えを持っていますか？

380 java  spring  dependency-injection  annotations  autowired 

現在のところ、この質問はQ＆A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 私が知りたいのですが、ここでの仕事と私たちのリード開発者の一人で、パターンとしてDIを導入しようとしている：どのような-もしあれば-あるマイナス面依存性の注入パターンを使用するには？ ここでは、トピックに関する主観的な議論ではなく、可能な限り完全なリストを探していることに注意してください。 明確化：私は依存性注入パターン（Martin Fowlerによるこの記事を参照）について話しているのですが、特定のフレームワークではなく、XMLベース（Springなど）でもコードベース（Guiceなど）でも、「自己ロール」 。 編集：ここで/ r / programmingを進行中のいくつかの素晴らしいディスカッション/怒り/討論。

336 design-patterns  dependency-injection 

Javaでは、IoC / DIは非常に一般的な手法であり、Webアプリケーション、ほぼすべての利用可能なフレームワーク、Java EEで広く使用されています。その一方で、大きなPython Webアプリケーションもたくさんありますが、Zope（コードで言うと恐ろしいはずですが）の他に、IoCはPythonの世界ではあまり一般的ではないようです。（私が間違っていると思われる場合は、いくつか例を挙げてください）。 もちろん、Pythonで使用できる一般的なJava IoCフレームワークのクローンがいくつかあります（たとえば、springpython）。しかし、どれも実際に使われているようには見えません。少なくとも、私はそのようなものを使用するDjangoまたはsqlalchemy + <insert your favorite wsgi toolkit here>ベースのWebアプリケーションに踏み込んだことはありません。 私の意見では、IoCには妥当な利点があり、たとえばdjango-default-user-modelを簡単に置き換えることができますが、PythonでのインターフェースクラスとIoCの広範な使用は、「pythonic」ではなく、少し奇妙に見えます。しかし、誰かがより良い説明をしているかもしれません。なぜIoCはPythonで広く使用されていないのでしょうか。

313 python  design-patterns  dependency-injection  inversion-of-control  architecture 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 3年前休業。 この質問を改善する 聖戦領域に足を踏み入れるリスクがある場合、これらの一般的なDI / IoCフレームワークの長所と短所は何ですか？..： Ninject ユニティ Castle.Windsor Autofac StructureMap ここに記載していない他のC＃のDI / IoCフレームワークはありますか？ 私のユースケースのコンテキストでは、クライアントWPFアプリとWCF / SQLサービスインフラストラクチャを構築しています。使いやすさ（特に明確で簡潔な構文に関して）、一貫したドキュメント、優れたコミュニティサポートとパフォーマンスはすべて重要な要素です私の選択で。 更新： 引用されているリソースと重複する質問は古くなっているようですが、これらすべてのフレームワークについての知識を持つ誰かが前に出て、実際の洞察を提供できますか？ 私はこのテーマに関するほとんどの意見が偏っている可能性があることを理解していますが、誰かがすべてのこれらのフレームワークを研究するために時間をかけ、少なくとも一般的に客観的な比較を持つことを望んでいます。 これまでに行われていない場合は、自分で調査することをいといませんが、これは少なくとも数人がすでに行っていることだと思いました。 2回目の更新： 複数のDI / IoCコンテナの経験がある場合は、それらの長所と短所をランク付けして要約してください。ありがとうございます。これは、人々が作成したあいまいな小さなコンテナーをすべて発見するための演習ではありません。人気のある（そしてアクティブな）フレームワークの比較を探しています。

308 c#  dependency-injection  unity-container  ioc-container  ninject 

どちらのパターンも、制御の反転の原則の実装のように見えます。つまり、オブジェクトは依存関係の構築方法を知らないはずです。 Dependency Injection（DI）は、コンストラクターまたはセッターを使用して依存関係を「注入」するようです。 コンストラクターインジェクションの使用例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo(IBar bar) { this.bar = bar; } //... } Service Locatorは「コンテナ」を使用しているようです。これは依存関係を結び付け、fooにバーを提供します。 サービスロケーターの使用例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo() { this.bar = Container.Get<IBar>(); } //... } 私たちの依存関係は単なるオブジェクトそのものなので、これらの依存関係には依存関係があり、さらに多くの依存関係があり、以下同様です。このようにして、Inversion of …

304 design-patterns  dependency-injection  service-locator 

ASP.NET Core MVC組み込みの依存関係注入フレームワークを使用して、型を手動で解決するにはどうすればよいですか？ コンテナの設定は簡単です。 public void ConfigureServices(IServiceCollection services) { // ... services.AddTransient<ISomeService, SomeConcreteService>(); } しかしISomeService、注入を実行せずに解決するにはどうすればよいですか？たとえば、私はこれをしたいです： ISomeService service = services.Resolve<ISomeService>(); にはそのようなメソッドはありませんIServiceCollection。

302 c#  dependency-injection  asp.net-core  asp.net-core-mvc