問題タブ [dependency-injection]

コントロールコンテナの独自の反転を構築しようとしています。現在、オブジェクトとそのタイプをディクショナリに保存し、要求されたときに参照を解決しています。しかし、参照または新しいインスタンスを解決できるようにしたいと考えています。Activator クラスを使用して新しいインスタンスを作成できます。しかし、解決するオブジェクトのコンストラクターが 1 つ、2 つ、または任意のパラメーターを取る場合はどうなるでしょうか。

たとえば、次のようなことが言えるようになりたいです。

そしてそれを次のように解決します

MyFoo は指定されたパラメータProxyでインスタンス化され、 MyBar はProxyとDataThingでインスタンス化されます。

それを実現するために解決は何をしなければなりませんか？

多くのプログラマーが順守しているように見えるのは、構成規則です。IoC のコンテキストでは、これは XML 構成の代わりに API を使用することを意味します。

構成の規則を使用するために抽象インターフェイス/クラスの具体的な実装を含む DLL を参照する必要がある場合、DI/IoC の背後にある疎結合のアイデアをどのように維持することになっていますか?

最近、Microsoft の Composite UI Application ブロックで構築されたアプリケーションのパフォーマンスの問題、特に読み込みに時間がかかりすぎる問題のトラブルシューティングを依頼されました。

これは、リフレクション/属性を使用してクラスを登録する Microsoft の ObjectBuilder 依存性注入フレームワークを中心に構築されています。プロファイリングは、ObjectBuilder が登録するものを検索する際に読み込まれたすべてのアセンブリのすべての型をスキャンするため、起動時にアプリがリフレクションにかなりの時間を費やしていることを示しました。

代替の DI フレームワークはすべて、属性、XML 構成、または純粋なコードも使用しているようです。
他の属性ベースのフレームワークがこれ以上優れているとは思えません。また、大量の XML を解析する必要がある起動時間などについても懐疑的です。
純粋なコードベースのフレームワークは、はるかに高速であるように見えますが、柔軟性もはるかに低いため、明確な良い選択があるようには見えません...

これにより、DI コンテナーのベンチマークを検索するようになりましたが、見つけることができたのはhttp://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.htmlだけです。
これは優れたベンチマークですが、コンテナーを使用して 100 万個のオブジェクトをどれだけ速く作成できるかを測定するだけです。私は 100 万個のオブジェクトを作成することに興味はありません。アプリをできるだけ早く起動したいだけなので、探しているのは DI コンテナーの起動コストに関する情報です。ブログの投稿、逸話、または「ObjectBuilder を高速化する方法は次のとおりです」と簡単です。

前もって感謝します

私は新しいプロジェクトを開始することを計画しており、現在最先端の Java Web フレームワークを検討しています。Guice を中心にアプリケーションを構築することにしました。Squill/JEQUEL/JaQu などの非常に軽量な ORM を使用する可能性がありますが、Web フレームワークを決定できません。このような軽量環境に最も適しているのはどれですか? また、Guice との統合に最も適しているのはどれですか?

新しいアプリケーションを開始するとき、既存の依存関係フレームワークをそのまま使用して、潜在的な欠点をリスクにさらしますか?それとも、完全に適応可能な独自のフレームワークを作成することを選択しますか?それはなぜですか?

標準的なアプローチに従う 3 層の .NET サービス アプリがあります。

私は途中で依存性注入について学ぼうとしていますが、これまでのところ、(Autofac を使用して) 素晴らしいことがわかりました。3 つの層のそれぞれは、さまざまなオブジェクトを作成する必要があり、場合によっては追加の構成などが必要になります。これを解決するには DI コンテナーが理想的であるように思われますが、システムの残りの部分との関係で、DI コンテナーがどこに存在するべきかを確認するのにいくつか問題があります。

現在、フロントエンドに DI コンテナーを構成するクラスがあります。それは基本的にコードの大きな束ですcontainer.Register<SomeType>()。

問題は、3 つの層すべてに対してコンテナーを構成しているため、データ アクセス レイヤーに関するかなり侵略的な知識が必要なことです。アプリを層に分割するポイントは、この正確な状況を回避することであるため、そのような知識を備えたフロントエンドにコードがあると、頭の中で警鐘が鳴らされます。
これは、データ アクセス レイヤーが単なる SQL サーバーではなく、多数の複雑な COM 相互運用機能と P/Invoke 呼び出しで構成されているため、DI に大きな影響を与えるという事実によっても悪化します。構成。

私はそれを分割することを考えました - おそらく層ごとに1つのコンテナーを持つか、グローバルDIコンテナーと通信して独自のビットを登録する「セットアップ」クラスを各層に持つことですが、それが原因かどうかはわかりません解決するよりも多くの問題...

多層アプリで DI を使用した経験を誰かが共有できれば、本当にありがたいです。

ありがとう、オリオン。

IoC コンテナーとしてウィンザー城を使用していますが、ちょっとした問題が発生しました。これはコードで最もよく説明されているので、試してみます。特定のインターフェイスの実装を提供するファクトリ クラスがあります。

ファクトリ クラスの実装は次のようになりますが、これが正しい方法かどうかはわかりません。IObjectCreator defaultCreator;

これで問題なく動作しますが、IObjectCreator インスタンスで特定の IObjectCreator を使用して子オブジェクトを作成する場合は、ObjectCreatorFactory を呼び出します。これにより、明らかに循環参照が発生します。

これはうまくいきません。作成されたオブジェクトが子オブジェクト作成者のファクトリを参照しているこのシナリオでは、どうすればよいでしょうか?

IC コンテナーを使用する場合、プリミティブ型をどのように処理しますか?

つまり、あなたが持っていると仮定します：

int および string コンストラクターの引数をどのように取得しますか?

これは私の StructureMap ブートストラップです:

.CacheBy(InstanceScope.HttpSession) を使用するように会話を設定すると、Object reference not found が表示されますが、CacheBy を使用しない場合は正常に動作します。これはセッションに入る必要がありますが、なぜこれが機能しないのかよくわかりません。

何か間違ったことをしていますか、それとも StructureMap のバグのように見えますか?