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

制御の反転（IoC）は、最初に遭遇したときに非常に混乱する可能性があります。 それは何ですか？ それはどの問題を解決しますか？ いつ使用するのが適切で、いつ使用しないのですか？

1826 oop  design-patterns  inversion-of-control 

私は現在このエラーを受けています： System.Data.SqlClient.SqlException：セッションで他のスレッドが実行されているため、新しいトランザクションは許可されません。 このコードを実行している間： public class ProductManager : IProductManager { #region Declare Models private RivWorks.Model.Negotiation.RIV_Entities _dbRiv = RivWorks.Model.Stores.RivEntities(AppSettings.RivWorkEntities_connString); private RivWorks.Model.NegotiationAutos.RivFeedsEntities _dbFeed = RivWorks.Model.Stores.FeedEntities(AppSettings.FeedAutosEntities_connString); #endregion public IProduct GetProductById(Guid productId) { // Do a quick sync of the feeds... SyncFeeds(); ... // get a product... ... return product; } private void SyncFeeds() { …

600 c#  entity-framework  transactions  inversion-of-control 

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

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

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 

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

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

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 

私のコンストラクターは次のようになり始めています： public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... ) パラメータリストは増え続けています。「コンテナ」は依存関係注入コンテナなので、なぜこれを実行できないのですか。 public MyClass(Container con) すべてのクラスで？欠点は何ですか？これを行うと、私は栄光のスタティックを使用しているように感じます。IoCと依存性注入の狂気についてのあなたの考えを共有してください。

300 c#  java  dependency-injection  inversion-of-control  ioc-container 

私は、いくつかの異なる高水準関数を持つC＃ライブラリの設計について考えています。もちろん、これらの高水準関数は、可能な限りSOLIDクラスの設計原則を使用して実装されます。そのため、コンシューマが定期的に直接使用することを目的としたクラスと、より一般的な「エンドユーザー」クラスの依存関係である「サポートクラス」が存在する可能性があります。 問題は、ライブラリを設計する最良の方法は何ですか？ DIに依存しない-1つまたは2つの一般的なDIライブラリ（StructureMap、Ninjectなど）に基本的な「サポート」を追加するのは妥当なようですが、コンシューマが任意のDIフレームワークでライブラリを使用できるようにしたいと思います。 非DI使用可能-ライブラリのコンシューマーがDIを使用していない場合でも、ライブラリは可能な限り使いやすく、これらの「重要でない」依存関係をすべて作成するためにユーザーが実行する必要がある作業量を削減する必要があります。彼らが使いたい「本物の」クラス。 私の現在の考えは、一般的なDIライブラリー（たとえば、StructureMapレジストリー、Ninjectモジュール）にいくつかの「DI登録モジュール」、および非DIであり、これらのいくつかのファクトリーへのカップリングを含むセットまたはファクトリー・クラスを提供することです。 考え？

230 c#  dependency-injection  inversion-of-control 

現在、nodejsを使用していくつかの実験プロジェクトを作成しています。私は多くのJava EE WebアプリケーションをSpringでプログラミングしており、依存関係の注入が容易であることを高く評価しています。 今私は興味があります：ノードで依存関係注入をどのように行うのですか？または：私も必要ですか？プログラミングスタイルが異なるため、置き換えの概念はありますか？ これまでは、データベース接続オブジェクトの共有などの簡単なことについて話していましたが、満足できる解決策が見つかりませんでした。

219 node.js  dependency-injection  inversion-of-control 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 依存性注入を説明する良い方法は何ですか？ Googleでいくつかのチュートリアルを見つけましたが、読者が単なるJava初心者であると想定するチュートリアルはありませんでした。これを初心者にどのように説明しますか？

208 design-patterns  dependency-injection  inversion-of-control 

私は長年のWindows開発者で、win32と初期のCOMに夢中です。2001年から.NETを使用しているため、C＃とCLRにかなり精通しています。Stack Overflowに参加し始めるまで、Castle Windsorについて聞いたことはありませんでした。Castle Windsorの「Getting Started」ガイドを読みましたが、クリックしていません。 この古い犬に新しいトリックを教え、Castle Windsorをエンタープライズアプリに統合する理由を教えてください。

190 c#  dependency-injection  inversion-of-control  castle-windsor 

Unityに関するMSDNの記事（依存性注入、制御の反転）を読んでいますが、簡単な用語（または簡単な例）で説明する必要があると思います。私はMVPCパターンに精通しています（ここではそれを使用しています）が、まだこのUnityのことを本当に理解できていないので、アプリケーション設計の次のステップだと思います。

157 c#  dependency-injection  inversion-of-control  unity-container 

私はクラスをリファクタリングし、それに新しい依存関係を追加しています。クラスは現在、コンストラクターで既存の依存関係を取得しています。そこで、一貫性を保つために、パラメーターをコンストラクターに追加します。 もちろん、いくつかのサブクラスに加え、ユニットテスト用のサブクラスもあります。そのため、すべてのコンストラクターを一致させるように変更するゲームをプレイしています。これには時間がかかります。 依存関係を取得するには、セッターでプロパティを使用する方がよいと思います。注入された依存関係は、クラスのインスタンスを構築するためのインターフェースの一部であるべきではないと思います。依存関係を追加すると、すべてのユーザー（サブクラスと直接インスタンス化するユーザー）が突然それを認識します。それはカプセル化の中断のように感じます。 これはここにある既存のコードのパターンではないようです。そのため、コンストラクタとプロパティの一般的なコンセンサス、長所と短所を調べています。プロパティセッターを使用する方が良いですか？

151 dependency-injection  inversion-of-control 

Unityにオブジェクトの作成を管理させようとしているのですが、実行時までわからないいくつかの初期化パラメーターが必要です。 現時点で私がそれを行う方法を考えることができる唯一の方法は、インターフェイスにInitメソッドを持つことです。 interface IMyIntf { void Initialize(string runTimeParam); string RunTimeParam { get; } } 次に、それを（Unityで）使用するには、次のようにします。 var IMyIntf = unityContainer.Resolve<IMyIntf>(); IMyIntf.Initialize("somevalue"); このシナリオでは、runTimeParamparamはユーザー入力に基づいて実行時に決定されます。ここでの些細なケースは単にの値を返しますrunTimeParamが、実際にはパラメーターはファイル名のようなものであり、initializeメソッドはファイルに対して何かを行います。 これにより、多くの問題が発生します。つまり、このInitializeメソッドはインターフェースで使用でき、複数回呼び出すことができます。実装にフラグを設定し、を繰り返し呼び出したときに例外をスローするのInitializeは、かなり不格好です。 インターフェイスを解決する時点では、の実装について何も知りたくありませんIMyIntf。しかし、私が欲しいのは、このインターフェースが特定の1回の初期化パラメーターを必要とするという知識です。オブジェクトを作成するときに、何らかの方法でこの情報を使用してインターフェイスに注釈（属性）を付け、それらをフレームワークに渡す方法はありますか？ 編集：インターフェースについてもう少し説明しました。

147 dependency-injection  inversion-of-control  unity-container  ioc-container  interface-design 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 この質問を改善する Enterprise Library Unityと他のIoCコンテナー（Windsor、Spring.Net、Autofacなど）を使用する場合の長所と短所は何ですか？

135 c#  .net  inversion-of-control  unity-container  enterprise-library