asp.net中控制反转的理解(文字+代码)
对IOC的解释为：“Inversionofcontrolisacommoncharacteristicofframeworks，sosayingthattheselightweightcontainersarespecialbecausetheyuseinversionofcontrolislikesayingmycarisspecialbecauseithaswheels.”
我想对这一概念执行一个个人的阐述，以方便我的理解。控制反转，从字面意思来看，就是控制权由被动变主动又变为被动，或被动变主动又变为被动。从这个角度来说，IOC就变得非常容易理解了。
举个例子：你的主管要求你做一件事情，这个时候就存在这么多个流程,主管命令你做事情（这个时候主动权在主管，你是被动的）
你接到命令做事情（这个时候主题是你，你是主动的，控制权在你手里）你完成事情（这个时候主题依然是你，控制权在你手里）
报告主管做完事情（主动权又叫交到主管手里了）
上面的整个流程就完成了一次IOC，从上面可以看出，IOC的基本思想是控制权的转换流程。
举个代码的例子：
假如有ClassA，ClassB，在A内部会原始化一个B，调用B的一个要领
DoMethodpublicClassB
{
publicvoidDoMethod（）
{
///dosomthing；
}
}
publicClassA
{
publicvoidExcute（）
{
Bb=newB（）；
b.DoMethod（）；
}
}
假如在Main函数中如下执行：Aa=newA（）；a.Excute（）；
从这两行代码来看，事实上也存在一个IOC的流程，a——>b——>a，理解的关键点就在在A的内部调用Excute的时候，要领b.DoMethod的执行。理解了IOC，我们再看一下DI，从上面A调用B我们可以看出，在原始化一个A的实例时，也必须实例化一个B，也就是说如果没有B或者B出了疑问，A就不能实例化，这就产生了一种依赖，就是A依赖B，这种依赖从设计的角度来说就是耦合，显然它是不能满足高内聚低耦合的要求的。这个时候就须要解耦，当然解耦有很多种要领，而DI就是其中一种。不管任何一种解耦要领，都不是说使A和B完全没有联系，而是把这种联系的实现变得隐晦，不那么直接，但是又很容易实现，而且易于扩展，不像上面的代码那样，直接new一个B出来。那为什么我们总是把IOC和DI联系到一起呢？是因为DI的基本思想就是IOC，而体现IOC思想的要领还有另外一个，那就是ServiceLocator，这个要领好像涉及到的很少。其实这些都是从java里面衍生出来的，虽然本人已经好几年没用java，里面Spring这些都会用到IOC、DI好像他们是紧密连接在一块的。