ASP.NET MVC不可或缺的部分——DI及其本质工作分析

IoC框架最本质的东西：反射或者EMIT来实例化对象。然后我们可以加上缓存，或者一些策略来控制对象的生命周期，比如是否是单例对象还是每次都生成一个新的对象。

DI实现其实很简单，首先设计类来实现接口，而不是把所有的程序逻辑写在一个类文件中，然后我们传入一个接口和一个继承自接口的类作为参数，然后我们在相应的函数那将泛型参数T作为形参，伪代码:

//调用部分

HandleDI<ITest, Test>

//实现部分

HandleDI<TInterface, T>

// 使用反射，EMIT，委托来实例化T创建TInterface的对象

然后我们使用反射或者EMIT或是委托TInterface对象。这就是DI的实现过程。

DI说白了，作用就是实例化继承自接口的类

之前对DI注入与控制器扩展竟然用依赖性解析器来实现，两个方面深感疑惑，由于越学越不懂，越学越头晕，因此就暂且放下了，接着学习，谁知道今天写程序涉及到这些，就继续研究了一下，哪知道，现在研究理解起来越来越顺手，思路也清晰，于是趁热打铁，大概的理解了一遍，虽说学习是个遗忘的过程，至少自己理解过就好...

对于自己现在能够很好地理解这块知识，我觉得是这个原因：学习是个循序渐进的过程，可以一开始我们遇到问题，略作思考研究，实在不行暂且放下，继续往下走，慢慢的等你学习的足够了，有了一定的知识体系，当你在遇到这样的问题时，你就能很好地解决它...

DI:依赖性注入是一种设计模式，用来实现程序块之间的松散耦合
DI容器:本质上是一个智能工厂，它为相互依赖的组件提供抽象，将依赖（低层模块）对象的获得交给第三方（系统）来控制，即依赖对象不在被依赖模块的类中直接通过new来获取，说白点就是创建对象的实例，并且实例化对象的依赖性。

控制器默认只能接受无参的构造函数，但，如果我们需要为其传递参数又该如何做呢？《利用MVC基本工具Ninject消除程序类之间的耦合的简单示例》实现了(相关分析请看《MVC模式中的DI与DI容器理解》)。可是，有个疑问：为什么要用到DI容器来做呢？甚至是依赖性解析器的方法来创建自定义控制器以实现控制器的重构(构造接收参数的控制器)？在我们一般的处理思路来看，应该是从其底层的实现模块来做，最基本的就是自定义控制器，可是为什么可以使用依赖性解析器呢？

分析:
构造有参数的控制器，本质上是重构控制器，向原有的控制器中注入参数，这其实就是依赖性注入DI的一种：构造器注入。我们向控制器的构造函数中传递参数使其能够接受参数:

public HomeController(IValueCalculator calcParam)
 {
 calc = calcParam;
 } 

我们为控制器注入了我们的依赖性——IValueCalculator接口，但是，当我们调试的时候，并不能够呈现出页面，相反会给我们报错，这是因为我们单单就是传入了参数而已，控制器的内部还是没有进行半点处理。我们使用依赖性解析器来进行处理，依赖性解析器可以用于实例化控制器。依赖性解析器有两个主要部件组成:
静态的DependencyResolver类，他对解析依赖性扮演着静态网关作用；
IDependencyResolver接口，该接口可以由知道如何解析依赖性的类来实现（通过使用DI容器），而且静态的DependencyResolver将进入该实现进行调用，以执行其工作。
最后DI容器与依赖性解析器就会重构控制器以实现控制器的参数化。
可以得出结论:控制器的参数化可以用依赖性解析器来重构控制器，是因为控制器的参数化，是利用构造器来注入的，构造器注入是依赖性注入的一种形式。DI容器是需要依赖性(一般是接口)的类(这里是控制器)和依赖性的具体实现(一般是接口的继承类)之间的一个第三方组件.依赖性解析器与DI容器两者相互依存

ASP.NET MVC的IOC注入有三种方式，也就是说我们有三种方式来重构控制器：
1.实现了IControllerFactory接口的DefaultControllerFactory；
2.实现了IDependencyResolver接口的DefaultDependencyResolver；
3.实现了IControllerActivator接口的DefaultControllerActivator；

最直接的就是自定义控制器工厂，在ASP.NET MVC 1.0时就是使用这种方法。具体的看《ASP.NET MVC使用自定义控制器工厂来实现IOC注入》
《MVC三个IOC注入点之Ninject使用示例》