如何在MVC网站的类项目部分中初始化Ninject [英] How to initialize Ninject in a class project part of an mvc site
问题描述
我在一个小项目中使用了Ninject，但现在将一个较大的Web应用程序转换为mvc，并且在使用Ninject方面需要帮助.在新解决方案中，我拥有mvc网站，并将某些功能拆分到了单独的类项目中，例如，我的ReportGenerator.
I have used Ninject in a small project, but am now converting a larger web app to mvc and need help with using Ninject. In the new solution, I have the mvc site and have split some of the functionality out into separate class projects, for example, my ReportGenerator.
我想在ReportGenerator中使用Ninject来解决它具有的依赖关系，但是我不希望MVC项目了解ReportGenerator的内部工作原理.那么我将在哪里创建绑定/内核?
I would like to use Ninject within ReportGenerator to resolve the dependencies it has, but I do NOT want the MVC project to know about the internal workings of ReportGenerator. So where would I create the bindings/kernel?
I've looked at other questions such as: Referencing Ninject in class library in ASP.NET MVC 3 application but that answer seems to state that the bindings are setup in the MVC project which I don't want.
有人可以指出我如何在MVC项目引用的类中配置/运行Ninject的示例代码吗?
Can someone point me to sample code of how to configure/run Ninject inside a class that's referenced by an MVC project that will also use Ninject?
推荐答案
You should register and resolve all your components in the Composition Root. This is unrelated to Ninject, and this advice will hold for all DI containers.
Composition Root是应用程序的启动路径，您可以在其中将所有内容连接在一起.通常，您将把这个合成根放置在启动项目中.您的情况就是您的MVC项目.
The Composition Root is the startup path of the application where you wire everything together. You would typically place this composition root inside your startup project; in your case your MVC project.
您通常不必为此担心，因为既然您的MVC程序集本身依赖于另一个程序集的细节，并不意味着您的UI逻辑(例如，您的控制器)就依赖于这些细节.如您所知，控制器应该仅依赖于抽象.不要将逻辑架构(分层)与物理架构(部署期间如何在磁盘上分离代码)混淆.合成根在逻辑上与您的MVC最终项目是分开的，尽管它可以位于同一程序集中.
You shouldn't typically be worried about this, because since your MVC assembly itself depends on the details of another assembly, doesn't mean that your UI logic (your controllers for instance) depend on those details. As you know the controllers should simply depend on abstractions. Don't confuse your logical architecture (separation of layers) with the physical architecture (how code is separated on disk during deployment). The Composition Root is logically separated from your MVC end project, although it could be located in the same assembly.
复合根通常是运行时首先运行的应用程序的代码路径，并且它必须了解每个人的所有知识.在控制台应用程序中，您的启动项目通常会非常非常薄，并且包含的内容并不多，而仅包含成分根.由于ASP.NET应用程序的体系结构，通常这很难实现，例如，因为启动项目是 Web应用程序，并且它包含各种类型的(控制器，视图等)需要解决.因此，对于Web应用程序来说，通常是将合成根目录"集成到Web项目本身中.再次，这不必担心，因为仅凭事实并不能使您的代码更紧密地耦合.
The Composition Root is typically the code path of your application that the runtime will run first, and it must know everything about everyone. In a console application the your startup project would typically be really, really thin, and contain not much but just the Composition Root. Because of the architecture of ASP.NET applications, this is typically much harder to achieve, for instance because the startup project is the web application and it contains all kinds of types (controllers, views, etc) that need to be resolved. Because of this, it is quite usual for web applications to have the Composition Root integrated into the web project itself. Again, this is not something to worry about, because the mere fact doesn't make your code more tightly coupled.
但是，当您的业务层被多个最终应用程序(例如，WCF Web服务和MVC应用程序)重用时，情况就不同了.为了防止代码重复，您可以将共享注册从MVC和WCF组合根目录移出，并将其放置在位于业务层(以及下面所有层)顶部的特殊引导程序"程序集中.这很简单，只要拥有一个带有静态方法的静态类，该静态方法将使用现有的Kernel实例并进行与业务相关的注册(大多数DI框架具有此功能，但是在大多数情况下它们是无用的，并且静态公共方法就可以了).每个合成根都可以创建自己的Kernel实例，进行注册，将该实例传递给BL引导程序，然后(可能)再进行一些注册，并存储供应用程序使用的内核.
Things gets different however, when you have a business layer that gets reused by multiple end applications (both a WCF web service and MVC app for instance). To prevent code duplication you would move the shared registrations out of the MVC and WCF composition root and place it in a special 'bootstrapper' assembly that sits on top of the business layer (and all layers below). This can be as simple as having a static class with a static method that takes in an existing Kernel instance and makes the business related registrations (most DI frameworks have features for this, but they are rather useless in most of the case and a static public method will do just fine). Each Composition Root can create their own Kernel instance, make registrations, pass the instance on to the BL bootstrapper, do -perhaps- some more registrations after that, and store the kernel for use by the application.
但是，即使在多个最终应用程序中，它们仍将各自包含自己的特定布线(因为每个应用程序都不同)，因此具有自己的合成根.
But even with multiple end applications, they will still each contain their own specific wiring (since every application is different) and thus have their own Composition Root.
这篇关于如何在MVC网站的类项目部分中初始化Ninject的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
