コンポジションルートでDIが発生することは、依存性注入の全体のポイントに反しますか？
私は、3つの基本的なレイヤーがある.NET MVC Webアプリケーションに依存性注入を使用しています。
1）Webアプリ2）サービスレイヤー3）データレイヤー
データレイヤーをサービスレイヤーに挿入し、サービスレイヤーをWebアプリのコントローラーに挿入しましたが、これらはすべて正常ですが、これらのクラスの登録がどこで行われるかについて混乱しています。
調査の結果、コンポジションルートはプロジェクト内のGlobal.asaxファイル内のWebアプリケーション内にあると言われましたが、これは、Webアプリケーション内のデータレイヤーへの参照が登録できます。これは、自分のWebアプリがデータレイヤーを認識したり気にしたりしたくないので、サービスレイヤーだけが参照を持っている必要があるため、DIが私にとってどのような目的に反するように思えますか？
コンポジションルートでDIが発生することは、依存性注入の全体的なポイントに反するのですか？
いいえ。オブジェクトグラフは Composition Root で作成する必要があります。
あなたの混乱の理由は理解できたと思います。そして、それはASP.NETプロジェクトに関連していると思います。これを説明するために、まずASP.NETを使用しない例を挙げましょう。
コンソールアプリケーションがあるとします。アプリケーションに必要なすべてのロジックを含むクラスライブラリをいくつか作成しました。
次のクラスライブラリを作成したとします。
- ApplicationLibraryには、アプリケーション自体に関連するクラスが含まれています。 UIロジックも含まれている場合があります。
- BusinessLogicLibraryには、ビジネスロジックに関連するクラスが含まれています。
- DataAccessLibraryには、データアクセスに関連するクラスが含まれています。
この場合のApplicationLibraryには、DataAccessLibraryへの参照がありません。
次に、これらの部分をコンソールアプリケーションプロジェクトで一緒に構成します。この場合のこのプロジェクトには、コンポジションルート以外は何も含まれていません。
ASP.NETプロジェクトの重要な点は、デフォルトで、コンポジションルートと一部のアプリケーション/ UIロジックが同じプロジェクトにあるテンプレートが取得されることです。
すばらしいのは、コンポジションルート（たとえば、IControllerFactory実装）のみを含むASP.NET Webプロジェクトがあることです。次に、コントローラーとビューを、コンポジションルートではなくなったため、DataAccessLayerへの参照を持たない別のクラスライブラリに移動します。
ASP.NETでこれを行うこともできます。簡単な方法があるかどうかはわかりません。