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