ninject - 如何在 mvc 站点的类项目部分中初始化 Ninject

Question

我在一个小项目中使用过 Ninject，但现在正在将一个较大的 Web 应用程序转换为 mvc，并且需要有关使用 Ninject 的帮助。在新的解决方案中，我拥有 mvc 站点并将一些功能拆分到单独的类项目中，例如我的 ReportGenerator。

我想在 ReportGenerator 中使用 Ninject 来解决它所具有的依赖关系，但我不希望 MVC 项目了解 ReportGenerator 的内部工作原理。那么我将在哪里创建绑定(bind)/内核？

我查看了其他问题，例如:Referencing Ninject in class library in ASP.NET MVC 3 application但该答案似乎表明绑定(bind)是在我不想要的 MVC 项目中设置的。

有人可以指出如何在一个也将使用 Ninject 的 MVC 项目引用的类中配置/运行 Ninject 的示例代码吗？

Answer 1

您应该在 Composition Root 中注册并解析所有组件。 .这与 Ninject 无关，此建议适用于所有 DI 容器。

组合根是应用程序的启动路径，您可以在其中将所有内容连接在一起。您通常会将此组合根放在您的启动项目中；在您的情况下，您的 MVC 项目。

您通常不应该担心这一点，因为您的 MVC 程序集本身依赖于另一个程序集的细节，并不意味着您的 UI 逻辑(例如您的 Controller )依赖于这些细节。如您所知， Controller 应该只依赖于抽象。不要将您的逻辑架构(层分离)与物理架构(代码在部署期间如何在磁盘上分离)混淆。组合根在逻辑上与您的 MVC 最终项目分离，尽管它可以位于同一个程序集中。

组合根通常是运行时首先运行的应用程序的代码路径，它必须了解每个人的一切。在控制台应用程序中，您的启动项目通常会非常非常薄，并且包含的​​内容不多，而仅包含 Composition Root。由于 ASP.NET 应用程序的架构，这通常更难实现，例如，因为启动项目是 Web 应用程序，它包含需要解析的各种类型( Controller 、 View 等)。因此，Web 应用程序通常会将 Composition Root 集成到 Web 项目本身中。同样，这不是什么值得担心的事情，因为仅仅是事实并不会使您的代码更紧密地耦合。

然而，当您有一个被多个终端应用程序(例如 WCF Web 服务和 MVC 应用程序)重用的业务层时，情况就不同了。为了防止代码重复，您可以将共享注册移出 MVC 和 WCF 组合根，并将其放置在位于业务层(以及下面的所有层)顶部的特殊“ Bootstrap ”程序集中。这可以像拥有一个带有静态方法的静态类一样简单，该静态方法采用现有的Kernel。实例并进行与业务相关的注册(大多数 DI 框架都有这方面的功能，但在大多数情况下它们相当无用，静态公共(public)方法就可以了)。每个组合根都可以创建自己的Kernel实例，进行注册，将实例传递给 BL Bootstrap ，之后可能会进行更多注册，然后存储内核以供应用程序使用。

但即使有多个终端应用程序，它们仍将包含自己的特定接线(因为每个应用程序都是不同的)，因此有自己的合成根。