我在一个小项目中使用过 Ninject，但现在我正在将一个较大的 Web 应用程序转换为 mvc，并且在使用 Ninject 方面需要帮助。在新的解决方案中，我拥有 mvc 站点并将一些功能拆分到单独的类项目中，例如我的 ReportGenerator。
我想在 ReportGenerator 中使用 Ninject 来解决它所具有的依赖关系，但我不希望 MVC 项目了解 ReportGenerator 的内部工作原理。那么我应该在哪里创建绑定/内核呢？
我查看了其他问题，例如：Referencing Ninject in class library in ASP.NET MVC 3 application，但该答案似乎表明绑定是在我不想要的 MVC 项目中设置的。
谁能指出我如何在一个也将使用 Ninject 的 MVC 项目引用的类中配置/运行 Ninject 的示例代码？
【问题讨论】：
标签： ninject
您应该在Composition Root 中注册并解析所有组件。这与 Ninject 无关，此建议适用于所有 DI 容器。
Composition Root 是应用程序的启动路径，您可以在其中将所有内容连接在一起。您通常会将此组合根放在您的启动项目中；在您的情况下，您的 MVC 项目。
您通常不必担心这一点，因为您的 MVC 程序集本身依赖于另一个程序集的细节，并不意味着您的 UI 逻辑（例如您的控制器）依赖于这些细节。如您所知，控制器应该只依赖于抽象。不要将您的逻辑架构（层分离）与物理架构（部署期间如何在磁盘上分离代码）混淆。组合根在逻辑上与您的 MVC 最终项目是分开的，尽管它可以位于同一个程序集中。
Composition Root 通常是运行时首先运行的应用程序的代码路径，它必须了解每个人的所有信息。在控制台应用程序中，您的启动项目通常会非常非常薄，并且包含的内容不多，而仅包含 Composition Root。由于 ASP.NET 应用程序的架构，这通常更难实现，例如，因为启动项目是 Web 应用程序，它包含各种类型（控制器、视图等）需要解决。因此，Web 应用程序通常会将 Composition Root 集成到 Web 项目本身中。再说一次，这不是什么值得担心的事情，因为仅仅是事实并不能使您的代码更紧密地耦合。
但是，当您的业务层被多个终端应用程序（例如 WCF Web 服务和 MVC 应用程序）重用时，情况就不同了。为了防止代码重复，您可以将共享注册移出 MVC 和 WCF 组合根，并将其放置在位于业务层（以及下面的所有层）顶部的特殊“引导程序”程序集中。这可以像拥有一个带有静态方法的静态类一样简单，该静态方法接受现有的Kernel 实例并进行与业务相关的注册（大多数 DI 框架都有这方面的功能，但在大多数情况下它们相当无用，并且静态公共方法就可以了）。每个 Composition Root 都可以创建自己的 Kernel 实例，进行注册，将实例传递给 BL 引导程序，之后可能进行更多注册，然后存储内核以供应用程序使用。
但即使有多个终端应用程序，它们仍将各自包含自己特定的接线（因为每个应用程序都不同），因此有自己的组合根。
【讨论】：