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

Question

我有一个解决方案,有两个相关的(对这个问题)项目,还有一些其他项目;

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

我的问题基本上是我应该使用Ninject 2做IoC,考虑到......

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

我把自己画成了一个心理角落,因为我只看到了三个选项.类库中的DI,Web应用程序中的DI,或两者都有,但每个都有问题:

• 我不能只在类库中做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.你可以在这个SO答案中阅读更多相关内容- 虽然这个问题是关于温莎的,但原理仍然是一样的.

那你的单元测试怎么样？他们也应该完全不了解DI容器.有关详细信息,请参阅此其他SO答案.

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