問題タブ [inversion-of-control]

Windsor/Microkernel について私が読んだことから、理論的には、xml ファイルを使用してコードで実行できることはすべて実行可能です。実際のところ、間違っていたら訂正してください。Windsor 層の主な貢献は、Microkernel が既に実行できることに対して xml 構成を追加することのようです。

ただし、コードでもう少し複雑な機能を実装する方法 (つまり、デフォルトのコンストラクター引数値を割り当てる方法) を見つけるのに最近苦労しています。現在、本番リリースで xml を使用する予定ですが、テスト用のコードでコンポーネントを登録していますが、これはかなり問題になっています。これは、彼らのドキュメントの不幸な状態と、私が見つけることができる唯一の記事がxml登録に焦点を当てているという事実によって助けられていません.

物事をコードに登録する方法をリストしているソースを知っている人はいますか (できれば xml に相当するものを使用してください)。その存在を抜きにして、Castle Windsor/Microkernel の xml 以外の重要な使用があるオープン ソース/サンプル プロジェクトを知っている人はいますか?

重複の可能性:
調べる価値のある .NET 依存性注入フレームワークはどれですか?

StructureMap と Ninject の中で最も優れた IoC はどれですか?

これは以下とマージする必要があります:ベスト インジェクション フレームワーク

デフォルトの実装をデフォルトのコンストラクターにハードコーディングするよりも、IOCコンテナーを使用することの利点を誰かが説明できますか？

言い換えれば、このコードの何が問題になっていますか？

私の知る限り、このクラスはコンストラクターインジェクションを十分にサポートしているため、単体テストとモックを簡単に実行できます。それに加えて、デフォルトのコンストラクターはIOCコンテナーの計算オーバーヘッドを取り除きます（プロセス全体がはるかに透過的であることは言うまでもありません）。

IOCコンテナを使用することで私が見ることができる唯一の利点は、インターフェイスの実装を頻繁に切り替える必要がある場合です。私は何かが足りないのですか？

少し前からIoCを使っているのですが、MicrosoftのUnityフレームワーク（正式名称「Unity Application Block」）を使うべきか迷っています。誰もそれを使用した経験がありますか? そのため、IoC コンテナー コードをプロジェクトからプロジェクトにコピーしてきましたが、標準的なものを使用する方がよいと思います。IoC は、コンポーネント ベースのアプリケーションを疎結合して変更可能に保つという点で大きな違いを生むことができると思いますが、私は決して IoC の専門家ではないので、依存関係として隅に追いやられるフレームワークに切り替えるのは緊張しています。いつか立ち去りたいと思うでしょう。

MEF（Managed Extensibility Framework）は、既存のIoC / DIコンテナーでは解決できない問題をどのように解決しますか？

私が取り組んでいるペットプロジェクトにキャッスルウィンザーを使用しています。新しいオブジェクトを作成するには、コード内のさまざまな場所で IoC コンテナーを呼び出す必要があることに気付き始めています。このコンテナーへの依存関係により、コードの保守が難しくなります。

この問題を解決するために私が使用した2つの解決策があります

オブジェクトを作成する必要があるアプリケーションの部分に挿入できるコンテナのラッパーとして抽象ファクトリを作成しようとしました。これは機能しますが、キャッスルが独自のコンテナーを依存関係として注入するのに苦労するため、いくつかの欠点があります。そのため、手動で行う必要があります。この種のことは、IoC コンテナーの目的全体を無効にします。

メインの applicationcontroller クラスを使用して IoC コンテナーをラップし、中央のファクトリー/リポジトリーとして機能させました。これは非常に成功しましたが、このクラスは大きくなりすぎて、中心的な神のオブジェクトのように振る舞い、他のほとんどすべてのオブジェクトがそれを参照しています。

どちらのソリューションも機能しますが、どちらにも欠点があります。他の人が同じ問題を抱えていて、より良い解決策を見つけているかどうか、私は興味があります.

編集 問題は、オブジェクト B に依存するオブジェクト A ではありません。ここでは、通常、コンストラクター注入を使用するだけで、すべてが機能します。時々、タイプ A のオブジェクトが、存続期間中に可変数のタイプ B の他のオブジェクトを作成する必要がある場合があります。これを行う方法がわかりません。

@ブレア・コンラッド: メンテナンスの問題は今のところ深刻ではありません。いくつかのクラスは、container.Resolve<> を呼び出すコンテナー オブジェクトに依存していました。また、インフラストラクチャと思われるものに応じてコードを作成したくありません。私はまだ試している途中なので、このプロジェクトで ninject から城に切り替えるときに、多くのコードを変更する必要があることに気付きました。

@花:うーん。私はあなたの拳のソリューションが好きです。私が試した両方のソリューションから機能するものを組み合わせています。私はまだオブジェクトについて考えすぎていて、インターフェイス/責任について十分に考えていなかったと思います。専用の工場を試してみましたが、コンテナを舞台裏で使用してオブジェクトを作成したいと思いますが、コンテナをきれいな方法でオブジェクトにDIする方法がわかりませんでした。

Castle Windsor IoC コンテナーの xml 構成ファイルに intellisense を提供するために、Visual Studio ディレクトリにドロップする .xsd スキーマ ファイルを探しています。ダウンロードした Windsor のコードを調べるだけでなく、さまざまな方法でグーグル検索しました。多くの人が同じ質問をしているのを見ますが、答えはありません。そのような文書があるかどうか知っている人はいますか？

ApplicationSettingsクラスが、私のアプリケーションに適用される TimeoutPeriod、 DefaultUnitOfMeasure 、HistoryWindowSize などの設定の一般的なリポジトリであるとします。そして、MyClass がそれらの設定の 1 つである DefaultUnitOfMeasure を利用するとします。

Inversion of Control Containers の適切な使用についての私の読みは、コンストラクターでクラスの依存関係を定義することです。これについて間違っている場合は修正してください。

そして、次のような方法でクラスのインスタンス化を呼び出します

IDataSourceに具体的な実装が割り当てられ、default_uom が接続されてApplicationSettings.DefaultUnitOfMeasureプロパティからインスタンス化されます。しかし、これらすべてのフープがジャンプするために本当に必要なのかどうか疑問に思う. 私は何のために自分を設定していますか？

はい、私のクラスの多くはIoC.Containerに依存することになりますが、それは私のクラスのほとんどが持つ依存関係です。クラスが結合されている限り、それを最大限に活用する必要があるようです。アジャイルの達人、どこが間違っているか教えてください。

したがって、10個のオブジェクトがあり、それぞれに1〜3個の依存関係があります（緩い結合に関する限り、これは問題ないと思います）が、動作（タイムアウト、ウィンドウサイズなど）を定義するために使用できるいくつかの設定もあります。

制御の反転コンテナの使用を開始する前に、コンストラクターのサイズを推奨される「4未満」パラメーターに維持するために、複数の設定を必要とする各オブジェクトのファクトリと、場合によっては単純なObjectSettingsオブジェクトを作成していました。サイズ。私は現在、制御の反転を使用していますが、それに対するポイントはあまりわかりません。確かに、7つのパラメーターを持つコンストラクターを取得する可能性がありますが、誰が気にしますか？とにかく、それはすべてIoCによって記入されています。

私はここで何かが欠けていますか、それともこれは基本的に正しいですか？

重複の可能性:
MEF と MAF (System.AddIn) の選択

Managed Extensibility Framework は System.Addin の代わりになりますか? それとも補完的なものですか？