問題タブ [ioc-container]

StructureMap を既存の Web フォーム アプリケーションにフックしようとしているところです。これは Web フォームなので、セッター インジェクションを使用する必要がありますが、これは理想的ではありませんが、何もないよりはましです。

私が行き詰まっているのは、VB への変換です (私は現在 VB ショップで働いている C# 開発者です)。C# で正常に動作するカスタム スキャナーを作成しましたが、それを VB に変換する方法に完全に行き詰まっています。

元の C# は次のようになります。

私がVBで得ることができる最も近いものはこれです：

リフレクターが私を助けてくれることを望んでいましたが、それは私のものに似たコードを思いつき、それもコンパイルされません。

では、訳は？

ランタイム設定を外部 XML ファイルに保存する必要がある C# dll プロジェクトがあり、この dll は ASP.NET/ASP.NET MVC アプリケーションで使用され、ランタイム設定も外部ファイル。

特定の外部ファイル (または app.config/web.config) からロードされたランタイム設定でオブジェクトを作成するために使用でき、中程度の信頼で実行されている Web アプリケーションでも機能する IoC コンテナーはどれですか? ハウツー/チュートリアルは大歓迎です。

これまでのところ、次の記事しか見つかりませんでした。

• Castle Windsor を使用して構成ファイルを自動的に読み取る
• 文字列を取り除く (3): アプリの設定を次のレベルに引き上げる

アップデート

現在のレコード タイプに基づいて、dll から可変数の SMTP サーバーにメールを送信しています。タイプ A の場合、特定の SMTP サーバーとポートを使用しています。タイプ B の場合、サーバーとポートの値の代替セットを使用しています。もちろん、デプロイ後にこれらの値を変更できるようにしたいので、それらを XML ファイルに保存します。

SMTP 設定を 2 つのプロパティ (SMTPServer を String として、SMTPPort を Int32 として) を持つ SMTPConfiguration クラスとして保存している場合、指定されたレコード タイプに基づいて必要なオブジェクトを IoC コンテナーから返すことは可能ですか?返すオブジェクトを構築するためにランタイム設定を読み取るには?

Update2

構成ファイルに次のパラメーターを格納しているとしましょう: ASMTPServer、BSMTPServer、ASMTPPort、BSMTPPort。Castle DictionaryAdapter を使用して、これらすべての設定を AppConfiguration クラスのプロパティとして読み取ることができます。

タイプ A レコードをパラメータとして使用している場合、必要な SMTPConfiguration クラスが ASMTPServer および ASMTPPort 値を使用する必要があることを指定するための推奨される方法は何ですか (タイプ B レコードをパラメータとして使用している場合は、BSMTPServer および BSMTPPort 値を使用する必要があります) ) ? また、このプロセスで AppConfiguration が必要であることをどのように指定できますか?

ISubDependencyResolverのように機能するが、Release（...）もサポートするものを構築することは可能ですか？

BlenderのコンストラクターでFruitの派生クラスを解決できるようにしたい状況があります。

残念ながら、Appleは別のアセンブリにあり、必要になるまでロードしたくありません。何百もの異なる種類のフルーツがすべて独自のアセンブリを持っているからです。

ISubDependencyResolverは、私のフルーツの一部が使い捨てであることを除いて、これに最適です。そのため、それらを解放する方法が必要です。

DefaultDependencyResolverから派生することがこれを達成する唯一の方法ですか？

編集：より包括的な例。

基本的に、「新しいApple（）」を破棄する必要のある一時的なオブジェクトとして扱う方法が必要です。これでまったく別のトラックを使用できることを完全に嬉しく思いますが、タイプ「Apple」は解決時に（起動時ではなく）ロードする必要があります。

最近、初めてIoCコンテナーを使い始めましたが、それを使用するためのベスト プラクティスについての教育を受けていません。より具体的には、Unityを C# .NET プロジェクトで使用していますが、 Prismに付属していたので使い始めました。

コンテナを使用して「最上位」オブジェクトを解決すると、コンテナに基づいて注入された正しいオブジェクトが取得されます。ただし、子と子の子を持つオブジェクトがあり、IoC コンテナーからのデータがずっと必要であるが、その間ではない場合、ベスト プラクティスを明確に見ることができません。通常、IoC コンテナーの使用をどのように整理しますか?

最初は、最上位のコンテナーから必要なデータを抽出してこのデータを渡すのではなく、必要な場所にコンテナーを渡すと思います。しかし、注入されたインターフェースに加えて他の特定のデータを取るオブジェクトに到達すると、再び問題が発生します。オブジェクトを解決した後、プロパティまたは init-method を介してこれらを注入したくありません。

これが十分に明確であることを願っていますが、架空の (そして少しばかげた..) 例を見てみましょう。

したがって、この例はあまり意味がありませんが、本質は、私がしなければならないことと同じです。ViewModel クラスに渡すアプリケーション コマンドがいくつかあります。それらのいくつかは、何かを表示するコマンドをトリガーできる必要があるためです。また、一部のクラスで必要になる可能性がある共通ストレージなどもありますが、現在は中間クラスに渡されて格納されています。コマンドのみの場合、コマンドまたはコンテナを保存しても大したことはありませんが、典型的な IoC の使用法では、代わりに IoC コンテナを渡し、これを後でオブジェクトを解決するために使用しますか? また、顧客名などの特定のデータについてはどうでしょうか? これを Resolve() に渡すことはできないので、後で注入する必要がありますか?

申し訳ありませんが、これは私ができる限り短いものでした。同じ長さの回答は必要ありません;-) ..ただ; IoC コンテナーでこのようなことを行うベスト プラクティスは何ですか?

StructureMap には、スキャン時に規則を適用する機能があります。したがって、明示的な登録なしで IFoo => Foo です。

AutoFacで利用できる類似のものはありますか? 周りを見回しても、役立つものは何も見つかりません。

ありがとう、

リポジトリ クラス (DB アクセスに使用) にアクセスする必要があるモデル クラスがあります。

リポジトリ用のインターフェイスを作成し、適切な IRepository ベースのクラスをカスタム ControllerFactory を介してコントローラーに挿入するように Castle Windsor を正常に構成しました。

私のモデルで同じことを行う方法を理解するのにもう少し苦労しています。

Windsor を使用して MVC モデルに依存関係を挿入する方法を知っている人はいますか?

余談ですが、これを処理するために Windsor が必要な理由は、データがコントローラーにポストされると、MVC がモデルのインスタンスを自動的にインスタンス化するためです。この自動インスタンス化では、コンストラクター パラメーターを渡すことができません。

ASP.NET MVCモデルに依存関係を注入したいのですが、パイプラインのどこに注入を行うべきかわかりません。

ControllerFactoryを使用すると非常に簡単ですが、モデルを扱う場合はそれほど簡単ではありません。

ASP.NET MVC アプリケーション用の IoC コンテナーを選択する方法についてのガイダンスを探しています。

(たとえば) StructureMap、Ninject、Castle Windsor、Unity、autofac などの違いは何ですか? 1 つのライブラリを選択するのに役立つリソースへのヒントやリンクを誰か教えてもらえますか?

更新: IoC コンテナーの初期化の違いについて説明する1 つの質問 ( Enterprise Library Unity とその他の IoC コンテナー) があります。

しかし、ASP.NET MVC アプリケーションにとって一部の IoC コンテナーをより適切に選択できるような機能上の違いはありますか?

私は自分のコードで ( Ninjectを使用して) 依存性注入を使用していますが、DI コンテナーがコードのどこに収まるかの誤解によって引き起こされたパフォーマンスの問題に遭遇するまで、私はかなりうまくやっていると思っていました。DI フレームワークの使用方法に関する情報はたくさんあるようですが、使用しない場所や最適な使用方法 (少なくとも私が見つけたもの) についてはあまり多くありません。

いくつかのベスト プラクティスと思われるものを書き出して、他の人が私に同意するかどうか、他のベスト プラクティスが思いつくかどうかを確認しようと思いました。

• アプリケーションまたは AppDomain ごとに 1 つのカーネルを使用する
• 存続期間の長い Singleton オブジェクトのみに DI コンテナを使用し、存続期間の短い一時オブジェクトにはファクトリ (またはその他のメソッド) を使用します)。
• プロパティまたはフィールド注入よりもコンストラクター注入を優先する
• オブジェクトをリクエストし、構築しないでください
• 他?? 良いブログ全体/記事へのポインタ??

IoC フレームワークは DI をはるかに簡単にしますが、それができるのは DI だけではなく、DI 以外にも多くの利点を提供します。

このコメントは、DI と IoC に関する質問への回答の 1 つで見ました。誰かがこれをもう少し詳しく説明できますか? IoC のその他の利点は何ですか?