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