Injection by HandとNinjection (およびWhy use Ninject )を読んでいました。私は2つの混乱に遭遇しました：
手で注入する手法には既に慣れていますが、Ninjection には慣れていないため、完全なプログラムがどのように機能するかわかりません。おそらく、そのページで行われているように、プログラムを分割して示すのではなく、完全なプログラムを提供する方が役立つでしょう。
これがどのように物事を簡単にするのか、私はまだよくわかりません。私は何か重要なものを見逃していると思います。インジェクションのグループを作成してから、2 つの大きなグループを一度に切り替える場合に、インジェクション フレームワークがどのように役立つかはわかりますが (これは、とりわけモックに役立ちます)、それ以上のものがあると思います。それより。しかし、私は何がわからない。あるいは、ポイントを強調するために、なぜこれがエキサイティングなのかを示す例がもっと必要なだけかもしれません。
これがどのように物事を簡単にするのか、私はまだよくわかりません。私は何か重要なものを見逃していると思います。
それぞれが簡単に理解、再利用、保守できる個別の機能を提供する個別のコンポーネントを開発するだけでよいとしたら、それは素晴らしいことではないでしょうか。コンポーネントのみに取り組んだ場所。
そうすることを妨げているのは、これらのコンポーネントを何らかの方法で組み合わせて管理し、機能するアプリケーションに自動的にできるインフラストラクチャが必要なことです。これを行うインフラストラクチャー、つまり IOC フレームワークが利用可能です。
したがって、IOC フレームワークは、依存関係の管理、テスト、または構成に関するものではありません。代わりに、コンポーネントについてのみ作業して考えることができるようにすることで、複雑さを管理することが重要です。
特定のコード ブロックに必要なインターフェイスをモックすることで、コードを簡単にテストできます。また、コードの他の部分を壊すことなく、機能を簡単に交換することもできます。
結束と結合がすべてです。
小規模なプロジェクトではメリットが見られない可能性がありますが、小規模なプロジェクトを乗り越えると、システムに変更を加える必要があることが明らかになります。DIを使えば簡単です。
私はいくつかのフレームワークの自動配線の側面が本当に好きです...型をインスタンス化する必要があることを気にする必要がないとき。
編集: Ayende @ Rahien のこの記事 を読みました。そして、私は彼の主張を本当に支持します。
ほとんどのフレームワークを使用した依存性注入は、再コンパイルを必要とせずに実行時に構成できます。
依存関係の注入は、コード内の依存関係がほとんどないところまでコードを取得すると、非常に興味深いものになります。一部の依存性注入フレームワークでは、構成ファイルで依存性を定義できます。これは、コードを変更せずに変更する必要がある非常に柔軟なソフトウェアが必要な場合に非常に役立ちます。たとえば、ワークフロー ソフトウェアは、このタイプのソリューションの最有力候補です。