IOC コンテナーを使用すると、アプリケーションの速度が低下します。これは、ほとんどのコンテナーが内部で反射を使用するためです。また、コードを理解しにくくすることもあります (?)。明るい面で。より疎結合のアプリケーションを作成し、単体テストを容易にするのに役立ちます。IOC コンテナーを使用する/使用しないことについて、他に長所と短所はありますか?
9308 次
7 に答える
19
IOC コンテナーを単純な方法で使用している場合、リフレクションは起動時にのみ使用されます。アプリケーションは最初から配線されており、コンテナーからの介入なしで通常どおり実行されます。もちろん、実行を開始した後に IOC を使用して依存関係を解決している場合は、少し異なる可能性があります。ただし、毎回新しいインスタンスを作成するように構成していない限り、遅延解決してキャッシュすることを期待しています。時間。
コードを理解しにくくすることについては、まったく逆です。依存関係が明示的に示されているため、各コンポーネントの理解がはるかに容易になり、構成ファイルにより、アプリケーション全体がどのように連携しているかが明確になります。
于 2009-02-05T07:58:58.630 に答える
7
私が経験した短所は、一部の開発者が IoC を理解できないように見えることだと思います。理解していないという理由だけでそれに反対した人が何人かいました。（それが何かに反対する悪い理由だと言っているわけではありません。まったくそうではありません。）
それは常に誰かを混乱させるように見える少しの抽象化を追加しますが、ほとんどの場合、長所は短所をはるかに上回っていると思います.
于 2009-02-05T07:57:52.360 に答える
7
IOC の使い方を熟知していて、とにかく良いコードを書く傾向があるのであれば、最小のシステムを除くすべてのシステムで IOC によってコードが理解しやすくなると言っても過言ではありません。
ただし、ほとんどのクラス/メソッドが非常に大きく、リファクタリングの概念がまだ定着していない場所で作業している場合、IOC を使用しようとすると、ソフトウェアが理解しにくくなる可能性があります。また、IOC は、プロジェクトでプログラムを作成するすべての人から支援を受ける必要があるため、それも考慮に入れる必要があります。
IOC はケーキのアイシングだと思います。私はアイシングが好きですが、素敵なケーキの上だけです. ケーキがうまくいかない場合は、最初にケーキを整理します。
IOC を使用した場合のパフォーマンス オーバーヘッドに関しては、ほとんどの場合、これが問題になるとは思いません。オーバーヘッドが大きくなる必要はありません。今日の CPU の速度を考えると、ほとんどの実行時間はデータ アクセスに費やされる可能性があります。特定のコードで IOC が遅いことが判明した場合は、返されたオブジェクトのキャッシュを追加するか、そのコードだけからIOC を削除することを検討します。
于 2009-02-05T11:38:10.650 に答える
4
実行速度の低下についての仮定は、「CはC＃/Javaよりも速い」とほぼ同じ種類の議論だと思います。このステートメントは、特定の操作や構造的に単純なタスクに当てはまる場合がありますが、複雑さが増す瞬間には当てはまりません。
DIフレームワークを使用してオブジェクトの作成と依存関係に集中できるようにすることで、コードサイズが大きくなったときに、より効率的なシステムが作成されます。大規模なアプリケーションの場合、DIフレームワークベースのコードが他のソリューションよりも優れているとほぼ確信しています。ランタイムには冗長性がほとんどないため、効率を上げるのは困難です。追加のオーバーヘッドのほとんどは、最初のロード時でもあります。
高度なDIコンテナーを使用すると、コンテナーなしでしか夢にも思わない「スコープ」マジックを実行することもできます。スコーププロキシを使用すると、Springは次のことを実行できます。
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
事実上、10層のシングルトンオブジェクトを作成すると、セッションスコープの何かが突然表示されます。
セキュリティのようなものは、そうでない場合とはまったく異なる方法で注入できます。多くの場合、古典的なパラドックスがあります。多くの場合、GUIレイヤーには、セキュリティ権限に関する複雑な知識が必要です。多くの場合、サービスレイヤーもこれを必要としますが、多くの場合、詳細レベルが異なります（通常、GUIよりも詳細度が低くなります）。従来のアプローチは、パラメータとして送信するか、スレッドローカルに配置するか、サービスに問い合わせることです。春を使えば、必要な場所にそれを注入することができ、他の誰も知る必要はありません。
これにより、実際にはアプリケーション開発全体が変わります。私はこれに順応するのに本当に苦労しました、しかしこの苦痛の後、私はそれが物事がどうあるべきか（私たちがそれをすることを学んだ方法とは対照的に）本当にはるかに近いと思います。
したがって、DIフレームワークには、プログラムの作成方法を変える可能性があり、DIだけでなくさらに大きな影響が及ぶ可能性があると思います。これは、単に新しいを呼び出すための栄光の方法ではありません。
于 2009-02-05T08:40:39.047 に答える
3
これまでのすべての回答に同意します。
追加したいのは、少しオーバーヘッドが発生するため、小さなアプリケーションにはあまり適していないということです。
中規模以上のアプリケーションは、IoC を使用することで最も恩恵を受けます。
長所と短所の詳細については、この質問を確認することもできます:ウィンザー城には欠点がありますか?
于 2009-02-05T08:03:51.723 に答える
2
ほとんどの場合、「シングルトン」オブジェクトではすべての初期化が 1 回だけ実行されるため、パフォーマンスの低下に気付くことさえありません。また、IoC を使用するとコードの理解が異なると主張したいと思います。それとは対照的に、IoC スタイルの開発では、一貫性のある小さなクラスを作成する必要があり、その結果、理解しやすくなります。
于 2009-02-05T07:57:49.600 に答える
1
ビジネス アプリケーションを作成している場合、制御の反転と依存性注入のコンテナーを (他のアジャイル プラクティスやツールと組み合わせて) 使用すると、生産性と信頼性の面で役立ちます。
さらに、アプリケーションはおそらく CPU 時間の大部分をリソースの待機または人間の対話の待機に費やし、何も役に立たないでしょう。アプリケーションには、数マイクロ秒のリフレクションに十分な処理能力が必要です。
于 2009-02-05T18:22:44.220 に答える