コンポジションルートにすべてのコンポーネントを登録して解決する必要があります。これはNinjectとは関係がなく、このアドバイスはすべてのDIコンテナに当てはまります。
コンポジションルートは、すべてを相互に接続するアプリケーションの起動パスです。通常、このコンポジションルートはスタートアッププロジェクト内に配置します。あなたの場合、MVCプロジェクトです。
MVCアセンブリ自体は別のアセンブリの詳細に依存しているため、UIロジック(たとえばコントローラー)がそれらの詳細に依存しているわけではないため、通常はこれについて心配する必要はありません。ご存知のように、コントローラーは単純に抽象化に依存する必要があります。論理アーキテクチャ(レイヤーの分離)と物理アーキテクチャ(展開中にコードがディスク上でどのように分離されるか)を混同しないでください。コンポジションルートは、MVCエンドプロジェクトから論理的に分離されていますが、同じアセンブリ内に配置することもできます。
コンポジションルートは通常、ランタイムが最初に実行するアプリケーションのコードパスであり、すべての人についてすべてを知っている必要があります。コンソールアプリケーションでは、スタートアッププロジェクトは通常、非常に薄く、コンポジションルートだけが含まれています。ASP.NETアプリケーションのアーキテクチャのため、これを実現するのは通常はるかに困難です。たとえば、スタートアッププロジェクトはWebアプリケーションであり、解決する必要のあるすべての種類(コントローラー、ビューなど)が含まれているためです。このため、Webアプリケーションでは、CompositionRootがWebプロジェクト自体に統合されているのが一般的です。繰り返しになりますが、これは心配する必要はありません。単なる事実では、コードがより緊密に結合されるわけではないからです。
ただし、複数のエンドアプリケーション(たとえば、WCF WebサービスとMVCアプリの両方)で再利用されるビジネスレイヤーがある場合は、状況が異なります。コードの重複を防ぐには、共有登録をMVCおよびWCFコンポジションルートから移動し、ビジネスレイヤー(およびその下のすべてのレイヤー)の上にある特別な「ブートストラッパー」アセンブリに配置します。これは、既存のインスタンスを取り込んでビジネス関連の登録を行う静的メソッドを持つ静的クラスを持つのと同じくらい簡単Kernel
です(ほとんどのDIフレームワークにはこの機能がありますが、ほとんどの場合、静的パブリックメソッドはあまり役に立ちませんうまくいくでしょう)。各コンポジションルートは独自のコンポジションルートを作成できますKernel
インスタンスを作成し、インスタンスをBLブートストラッパーに渡し、その後、おそらくさらにいくつかの登録を行い、アプリケーションで使用するためにカーネルを保存します。
ただし、複数のエンドアプリケーションを使用する場合でも、それぞれに固有の配線が含まれているため(アプリケーションごとに異なるため)、独自のコンポジションルートがあります。