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