依存性注入は大きなオーバーヘッドを引き起こす可能性がありますか?
特にリゾルバーが何度も呼び出される場合(パターンの例を見ている可能性が非常に高い)、そう思いますか?それとも私の考えが間違っていますか?残念ながら、私はそれを使用したことはありませんが、使用する予定があるため、自分でテストすることはできません.
依存性注入は大きなオーバーヘッドを引き起こす可能性がありますか?
特にリゾルバーが何度も呼び出される場合(パターンの例を見ている可能性が非常に高い)、そう思いますか?それとも私の考えが間違っていますか?残念ながら、私はそれを使用したことはありませんが、使用する予定があるため、自分でテストすることはできません.
Service locatorを使用していない限り、オーバーヘッドが大きな違いを生むとは思えません。(たとえそうであっても、それが重要である可能性は低いです。)
コンストラクター注入と最新のフレームワークを使用すると、オブジェクトが構築されるときにリゾルバーが呼び出されます。ほとんどの場合、依存関係を持つオブジェクトは、比較的高レベルのコンポーネントであるか、寿命が長いか、またはその両方であることがわかると思います。
IoC コンテナーを使用していて、タイトなループで依存関係を持つ多数のオブジェクトを作成している場合は、いくつかの最適化が必要になる場合があります。いつでもプロファイリングまたはベンチマークできます。
要するに、私はそれについて心配する必要はありません。
概念としての依存性注入は、高いオーバーヘッドを持つ必要はありません。コードに組み込まれるのではなく、実行時に他のクラスへの接続を構築できるようにクラスを構造化するだけです。
もちろん、オーバーヘッドが高いランタイム接続を構築する方法はいくつかあります。それらの方法は避けてください。
いくつかのパフォーマンステストについては、http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.htmlを参照してください。各テストは1000000回の作成を実行していました。
ベンチマークはシングルトン解像度と一時的な解像度を示していることに注意してください。シングルトンは、クラスのインスタンスを登録します(Unityを使用)。
container.RegisterInstance<IMyType>(new ConcreteMyType());
そして、このインスタンスは毎回返されます(これは非常に高速です)。
トランジェントとは、クラスタイプのみを登録し、IoCフレームワークがクラスタイプを作成する役割を果たします(Unityの場合)。
container.RegisterType<IMyType, ConcreteMyType>();
これには、シングルトンを返すよりも時間がかかります。
全体的な最適化の観点から、依存性注入のオーバーヘッドは小さなビールです。他のパフォーマンスのボトルネックは、最適化するものである可能性が高くなります。
依存性注入によって大きなオーバーヘッドが発生することはありません。きっとどこかでボトルネックが見つかるはずです。オーバーヘッドが気になる場合は、C# は使用したくない言語である可能性があります。C# がもたらすメリットのために C# を使用すると、扱いたくない詳細がいくつか抽象化されます。
DI と同様に、アプリケーションを疎結合にするなどの利点もあり、将来の保守が容易になります。
依存性注入自体は単なる間接的なものであるため、オーバーヘッドはありますが、実際にはごくわずかです。実行時のパターン マッチングと解決は別の問題です (ただし、依存性注入でよく使用されますが、DIがそのような追加機能を要求するわけではありません;-)。
オーバーヘッドとテスト可能で保守可能なコード...私はテスト可能で保守可能なコードを選択します(より高速なコンピューターをいつでも購入できます)
=)