问题
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.
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.
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?
回答1:
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.
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.
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.
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.
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.
来源：https://stackoverflow.com/questions/13327940/how-to-initialize-ninject-in-a-class-project-part-of-an-mvc-site