私はキャッスル プロジェクト、特にウィンザーを調査しています。私は、このテクノロジーで何が可能になるかに非常に感銘を受けました。このような疎結合システムを持つことの利点は明らかです。私が確信していない唯一のことは、特にasp.netで、この方法を使用することに欠点があるかどうかです? たとえば、パフォーマンス ヒットなどです。
私はこのアプローチの利点をここにいる仲間の開発者に見えるようにしようとしていますが、次のような反響があります。
これはリフレクションを使用しており、コンテナからオブジェクトが呼び出されるたびにリフレクションを使用する必要があるため、パフォーマンスが大幅に低下します。(これは事実ですか?すべての呼び出しでリフレクションを使用しますか?)
インターフェイスに依存している場合。クラスに追加された追加のメソッドとプロパティを持つオブジェクトを処理するにはどうすればよいですか? (継承による)
質問に答えるには:
- これはリフレクションを使用しており、コンテナからオブジェクトが呼び出されるたびにリフレクションを使用する必要があるため、パフォーマンスが大幅に低下します。(これは事実ですか?すべての呼び出しでリフレクションを使用しますか?)
- インターフェイスに依存している場合。クラスに追加された追加のメソッドとプロパティを持つオブジェクトを処理するにはどうすればよいですか? (継承による)
クラス コンポーネントを使用することもできますが、制限があり、そのことを認識しておく必要があります (たとえば、非仮想メソッドの呼び出しをインターセプトできないなど)。私は、Windsor が最も成熟しており、私のスタイルの開発コンテナーに最も適していることを発見しました。
それ以外に、パフォーマンス、容認できないパフォーマンスのために依存関係コンテナーを破棄しなければならなかったプロジェクトについて聞いたことがありません。Windsor は非常に優れており、時間のかかる操作の結果をキャッシュに保存するので、2 度料金を支払う必要がありません。多くの IoC コンテナーの速度を比較するグラフがインターネットで見つかる場合があります。これらについて注意すべき点が 2 つあります。すべてのコンテナーは非常に高速です。これらのチャートで他のコンテナが Windsor よりも高速であるという事実は、それらが優れていることを意味するとは考えないでください。Windsor は、他のコンテナーにはない多くのことを行います。
IoC コンテナー (Spring.NET および StructureMap) をいくつかの本番アプリで高負荷 (Facebook/MySpace の高負荷ではなく、いくつかのサーバーに負荷をかけるのに十分) で使用しました。
私の経験では、IoC を使い始める前から、パフォーマンスに関する最大の懸念事項は、データベースとデータベースとのやり取り (クエリ、インデックスの最適化、第 2 レベルのキャッシュの使用など) です。
アプリにデータベースが関係している場合、Windsor やその他のコンテナーが引き起こす可能性のあるパフォーマンス ヒットは、DB ラウンド トリップに比べて非常に小さいものになります。
これは、new() 演算子と Activator.CreateInstance() のパフォーマンス ヒットを 1 ～ 10 ミリ秒で比較する人々のようなものですが、通常、単一の DB ラウンドトリップは桁違いに高価です。
小さなことは気にせず、大きなことに集中することをお勧めします。
また、StructureMap を検討することをお勧めします。これは、Windsor よりもはるかに多くの機能があり、Windsor の多くの欠点 (つまり、参照を保持し、それらを解放する必要があるなど) がないためです。 .
私が遭遇した Castle Windsor の問題の 1 つは、Medium Trust で実行できないことです (私が実行できなかった再コンパイルなしでは)。そのため、Windsor から Unity に切り替える必要がありました。
DI/IoC のパフォーマンスによると、パフォーマンスへの影響はそれほど大きくないと思います。特に、そのパワーを念頭に置いている場合はそうです。
ところで: DI/IoC を初めて使用する場合は、この MSDN の記事を読む必要があります。
かなりの起動コスト、操作中のパフォーマンスへの影響はほとんどありません (もちろん、呼び出しに対する反映はありません - インスタンス化中にすべてがコンパイルされます)。ウィンザーは少し重いですが、適切な寿命管理を行えば問題はありません。
より重要な欠点は、統合の問題がビルド中に発見されず、起動時にさえ発見されないことです。すべてのモジュールのバージョンを注意深く追跡し、システム全体を継続的にテストしないと、問題が発生しやすくなります。ここではリフレクションが役立つため、Windsor は他の多くの DI フレームワークよりもその点で優れています。
私の経験では IoC コンテナのパフォーマンスが受け入れられない唯一の例外は、ComponentModel で使用するために IoC コンテナを IServiceProvider として統合/ラップしようとする場合です。ある種のカスタム デザイナー、つまりワークフロー/フローチャートなどを構築します)。
多数の winforms コンポーネントが動作する方法により、特に設計時に、フレームワークが 1 秒間に 30,000 回以上のサービス解決呼び出しを行うことができるため、コンポーネントを解決するコストにより、ドラッグ時にマウスが物理的に「スタッター」します。私が思うに、コンポーネント自体の不適切なコーディング慣行への反映、または少なくともサービスプロバイダーの実装が高速/シンプルであるという仮定が原因です。
実際には、負荷の高い商用アプリケーションであっても、コンポーネントの解決時間が問題になることは一度もありません。
パフォーマンスについては、次の記事を参照してください。
ただし、これらのコンテナーの一部には、より新しい (そしておそらくより高速な) バージョン (特に Unity) があることに注意してください。
- これはリフレクションを使用しており、コンテナからオブジェクトが呼び出されるたびにリフレクションを使用する必要があるため、パフォーマンスが大幅に低下します。(これは事実ですか?すべての呼び出しでリフレクションを使用しますか?)
知る限り、すべての優れたコンテナー (ここに含まれる Castle Windsor) は、リフレクションを使用して新しいインスタンスを作成します。ただし、これはパフォーマンスの向上です。これは、はるかに遅い Activator.CreateInstance と比較するためのものです。ただし、他の一部のコンテナは非常に高速であり、新しいオペレーターと競合できます。ここで比較ベンチマークを参照してください。Castle Windsor は高性能のものではありませんが、速度はそれほど重要ではありません。アプリケーションでの IoC の使用に関しては。クラスの 90% をシングルトーンとして設定する必要があります。これは、アプリケーションの起動時にのみ機能することを意味します。
- インターフェイスに依存している場合。クラスに追加された追加のメソッドとプロパティを持つオブジェクトを処理するにはどうすればよいですか? (継承による)
このチュートリアルとこのチュートリアルを試してください。それはあなたの質問への答えを明らかにします。設計上の問題を回避し、ソフトウェアの保守を容易にしたい場合は、SOLID プラクティスを強くお勧めします。