我应该在哪里注射Ninject 2+（我如何安排我的模块？）

Question

我有一个解决方案，有两个相关的（对这个问题）项目，还有一些其他项目;

1. 具有其他几个项目使用的功能的类库。
2. ASP.NET MVC应用程序。

我的问题基本上是我应该使用Ninject 2进行IoC，考虑到......

• 类库需要一些DI爱，其中包括需要特定于Web请求的会话对象的存储库类（想想工作单元）。
• MVC应用程序需要DI，因为在Ninject 2中你基本上都是从NinjectHttpApplication继承的。
• 类库的单元测试需要注意这一点，以注入一组不同的存储库。
• 出于同样的原因，需要注入Web应用程序的单元测试。

我把自己画成了一个精神角落，因为我只看到了三个选项。类库中的DI，Web应用程序中的DI，或两者都有，但每个都有问题：

• 我不能在类库中只进行 ，因为MVC应用程序需要从NinjectHttpApplication继承而开始。
• 我不能只在MVC应用程序中执行DI - 毕竟，其他库使用类库，而且MVC应用程序不应该对库的内部结构有太多了解。
• 我想这是我能看到的唯一出路：两个项目的独立IoC。类库和MVC应用程序都有自己的IoC设置，并为他们的东西做DI，而不是真正关心彼此。

有没有人对如何做这样的事情有一些“最佳实践”或指导方针？我无法想象我是第一个在这种情况下最终结束的人，而且知道“正确”的做法是什么肯定会很好......

谢谢！

Answer 1

我不知道NInject，但除非它与Windsor，StructureMap等大不相同，否则答案往往保持不变，因为有一些常见的DI模式。考虑到这一点：

首先要意识到DI并不依赖于特定的框架，如NInject或Windsor。这是一套技术和设计模式。您可以使用所谓的穷人的DI手动进行DI，但显然使用DI容器会更好。

为什么这有关系？它是相关的，因为一旦你意识到这一点，结果是你的应用程序的绝大部分代码应该没有知道DI容器。

那么你在哪里使用DI容器？它只应在组合根中使用，在您的情况下，它将对应于Global.asax。您可以在this SO answer中阅读更多相关信息 - 虽然这个问题与温莎有关，但原则仍然相同。

那么你的单元测试怎么样？他们也应该完全不了解DI容器。有关详细信息，请参阅this other SO answer。

通过大量使用构造函数注入，可以在您的库中实现DI。您不需要引用任何DI容器来执行此操作，但如果您使用DI容器来解析组合根中的所有依赖项，则会使生活变得更加轻松。