1.IOC的理论背景
2.什么是IOC
3.IOC也叫依赖注入(DI)
4.IOC的优缺点
5.IOC容器的技术剖析
6.IOC容器的一些产品
7.参考博文
本文旨在用语言(非代码)说清楚IOC到底是什么，没有什么高深的技术，园中的老牛、大虾们看到这里可以绕行了，以免浪费您宝贵的时间。IOC这个东西DebugLZQ早就想写了，但是出于对文章权威性的考虑(不能误人子弟- -!)，本文主要内容来源于最近LZ看的一些国内外的关于IOC的博文、博问，所有引用到的文章，在参考博文中均已注明。
1.IOC的理论背景
我们知道在面向对象设计的软件系统中，它的底层都是由N个对象构成的，各个对象之间通过相互合作，最终实现系统地业务逻辑[1]。
图1 软件系统中耦合的对象
如果我们打开机械式手表的后盖，就会看到与上面类似的情形，各个齿轮分别带动时针、分针和秒针顺时针旋转，从而在表盘上产生正确的时间。图1中描述的就是这样的一个齿轮组，它拥有多个独立的齿轮，这些齿轮相互啮合在一起，协同工作，共同完成某项任务。我们可以看到，在这样的齿轮组中，如果有一个齿轮出了问题，就可能会影响到整个齿轮组的正常运转。
齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。现在，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。
图2 对象之间的依赖关系
耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson 1996年提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中。
2.什么是IOC
IOC是Inversion of Control的缩写，多数书籍翻译成“控制反转”。
1996年，Michael Mattson在一篇有关探讨面向对象框架的文章中，首先提出了IOC 这个概念。对于面向对象设计及编程的基本思想，前面我们已经讲了很多了，不再赘述，简单来说就是把复杂系统分解成相互合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展。
IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。如下图：
图3 IOC解耦过程
大家看到了吧，由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。
我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：
图4 拿掉IOC容器后的系统
我们现在看到的画面，就是我们要实现整个系统所需要完成的全部内容。这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现A的时候，根本无须再去考虑B、C和D了，对象之间的依赖关系已经降低到了最低程度。所以，如果真能实现IOC容器，对于系统开发而言，这将是一件多么美好的事情，参与开发的每一成员只要实现自己的类就可以了，跟别人没有任何关系！
我们再来看看，控制反转(IOC)到底为什么要起这么个名字？我们来对比一下：
软件系统在没有引入IOC容器之前，如图1所示，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。
软件系统在引入IOC容器之后，这种情形就完全改变了，如图3所示，由于IOC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
通过前后的对比，我们不难看出来：对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。
3.IOC也叫依赖注入(DI)
2004年，Martin Fowler探讨了同一个问题，既然IOC是控制反转，那么到底是“哪些方面的控制被反转了呢？”，经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上给出了实现IOC的方法：注入。所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
所以，依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。
学过IOC的人可能都看过Martin Fowler(老马,2004年post)的这篇文章：Inversion of Control Containers and the Dependency Injection pattern[2]。
博客园的园友EagleFish(邢瑜琨)的文章： 深度理解依赖注入（Dependence Injection）[3]对老马那篇经典文章进行了解读。
CSDN黄忠成的Inside ObjectBuilder[4]也是，不过他应该来自台湾省，用的是繁体，看不管繁体中文的，可以看园中的吕震宇博友的简体中文版[转]Object Builder Application Block[5] 。
4.IOC的优缺点
In my experience, IoC using the Spring container brought the following advantages[6]:
- flexibility
- changing the implementation class for a widely used interface is simpler (e.g. replace a mock web service by the production instance)
- changing the retrieval strategy for a given class is simpler (e.g. moving a service from the classpath to the JNDI tree)
- adding interceptors is easy and done in a single place (e.g. adding a caching interceptor to a JDBC-based DAO)
- readability
- the project has one unified and consistent component model and is not littered with factories (e.g. DAO factories)
- the code is briefer and is not littered without dependency lookup code (e.g. calls to JNDI InitialContext)
- testability
- dependencies are easy to replace mocks when they're exposed through a constructor or setter
- easier testing leads to more testing
- more testing leads to better code quality, lower coupling, higher cohesion
使用IOC框架产品能够给我们的开发过程带来很大的好处，但是也要充分认识引入IOC框架的缺点，做到心中有数，杜绝滥用框架[1]。
第一、软件系统中由于引入了第三方IOC容器，生成对象的步骤变得有些复杂，本来是两者之间的事情，又凭空多出一道手续，所以，我们在刚开始使用IOC框架的时候，会感觉系统变得不太直观。所以，引入了一个全新的框架，就会增加团队成员学习和认识的培训成本，并且在以后的运行维护中，还得让新加入者具备同样的知识体系。
第二、由于IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。如果你要追求运行效率的话，就必须对此进行权衡。
第三、具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。
第四、IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险。
我们大体可以得出这样的结论：一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品，像WEB2.0网站就是这种情况。
5.IOC容器的技术剖析
IOC中最基本的技术就是“反射(Reflection)”编程，目前.Net C#、Java和PHP5等语言均支持，其中PHP5的技术书籍中，有时候也被翻译成“映射”。有关反射的概念和用法，大家应该都很清楚，通俗来讲就是根据给出的类名（字符串方式）来动态地生成对象。这种编程方式可以让对象在生成时才决定到底是哪一种对象。反射的应用是很广泛的，很多的成熟的框架，比如象Java中的Hibernate、Spring框架，.Net中 NHibernate、Spring.Net框架都是把“反射”做为最基本的技术手段。
6.IOC容器的一些产品
Sun ONE技术体系下的IOC容器有：轻量级的有Spring、Guice、Pico Container、Avalon、HiveMind；重量级的有EJB；不轻不重的有JBoss，Jdon等等。Spring框架作为Java开发中SSH(Struts、Spring、Hibernate)三剑客之一，大中小项目中都有使用，非常成熟，应用广泛，EJB在关键性的工业级项目中也被使用，比如某些电信业务。
.Net技术体系下的IOC容器有：Spring.Net、Castle等等。Spring.Net是从Java的Spring移植过来的IOC容器，Castle的IOC容器就是Windsor部分。它们均是轻量级的框架，比较成熟，其中Spring.Net已经被广泛应用于各种项目中。
深度理解依赖注入（Dependence Injection）
前面的话：提到依赖注入，大家都会想到老马那篇经典的文章。其实，本文就是相当于对那篇文章的解读。所以，如果您对原文已经有了非常深刻的理解，完全不需要再看此文；但是，如果您和笔者一样，以前曾经看过，似乎看懂了，但似乎又没抓到什么要领，不妨看看笔者这个解读，也许对您理解原文有一定帮助。
1.依赖在哪里
老马举了一个小例子，是开发一个电影列举器（MovieList），这个电影列举器需要使用一个电影查找器（MovieFinder）提供的服务，伪码如下：
2public interface MovieFinder {
3 ArrayList findAll();
4}
5
6/*服务的消费者*/
7class MovieLister
8{
9 public Movie[] moviesDirectedBy(String arg) {
10 List allMovies = finder.findAll();
11 for (Iterator it = allMovies.iterator(); it.hasNext();) {
12 Movie movie = (Movie) it.next();
13 if (!movie.getDirector().equals(arg)) it.remove();
14 }
15 return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
16 }
17
18 /*消费者内部包含一个将指向具体服务类型的实体对象*/
19 private MovieFinder finder;
20 /*消费者需要在某一个时刻去实例化具体的服务。这是我们要解耦的关键所在，
21 *因为这样的处理方式造成了服务消费者和服务提供者的强耦合关系（这种耦合是在编译期就确定下来的）。
22 **/
23 public MovieLister() {
24 finder = new ColonDelimitedMovieFinder("movies1.txt");
25 }
26}
从上面代码的注释中可以看到，MovieLister和ColonDelimitedMovieFinder（这可以使任意一个实现了MovieFinder接口的类型）之间存在强耦合关系，如下图所示：
这使得MovieList很难作为一个成熟的组件去发布，因为在不同的应用环境中（包括同一套软件系统被不同用户使用的时候），它所要依赖的电影查找器可能是千差万别的。所以，为了能实现真正的基于组件的开发，必须有一种机制能同时满足下面两个要求：
（1）解除MovieList对具体MoveFinder类型的强依赖（编译期依赖）。
（2）在运行的时候为MovieList提供正确的MovieFinder类型的实例。
换句话说，就是在运行的时候才产生MovieList和MovieFinder之间的依赖关系（把这种依赖关系在一个合适的时候“注入”运行时），这恐怕就是Dependency Injection这个术语的由来。再换句话说，我们提到过解除强依赖，这并不是说MovieList和MovieFinder之间的依赖关系不存在了，事实上MovieList无论如何也需要某类MovieFinder提供的服务，我们只是把这种依赖的建立时间推后了，从编译器推迟到运行时了。
依赖关系在OO程序中是广泛存在的，只要A类型中用到了B类型实例，A就依赖于B。前面笔者谈到的内容是把概念抽象到了服务使用者和服务提供者的角度，这也符合现在SOA的设计思路。从另一种抽象方式上来看，可以把MovieList看成我们要构建的主系统，而MovieFinder是系统中的plugin，主系统并不强依赖于任何一个插件，但一旦插件被加载，主系统就应该可以准确调用适当插件的功能。
其实不管是面向服务的编程模式，还是基于插件的框架式编程，为了实现松耦合（服务调用者和提供者之间的or框架和插件之间的），都需要在必要的位置实现面向接口编程，在此基础之上，还应该有一种方便的机制实现具体类型之间的运行时绑定，这就是DI所要解决的问题。
2.DI的实现方式
和上面的图1对应的是，如果我们的系统实现了依赖注入，组件间的依赖关系就变成了图2：
图2
说白了，就是要提供一个容器，由容器来完成（1）具体ServiceProvider的创建（2）ServiceUser和ServiceProvider的运行时绑定。下面我们就依次来看一下三种典型的依赖注入方式的实现。特别要说明的是，要理解依赖注入的机制，关键是理解容器的实现方式。本文后面给出的容器参考实现，均为黄忠成老师的代码，笔者仅在其中加上了一些关键注释而已。
2.1 Constructor Injection（构造器注入）
我们可以看到，在整个依赖注入的数据结构中，涉及到的重要的类型就是ServiceUser, ServiceProvider和Assembler三者，而这里所说的构造器，指的是ServiceUser的构造器。也就是说，在构造ServiceUser实例的时候，才把真正的ServiceProvider传给他：
2{
3 //其他内容，省略
4
5 public MovieLister(MovieFinder finder)
6 {
7 this.finder = finder;
8 }
9}
2 MutablePicoContainer pico = new DefaultPicoContainer();
3
4 //下面就是把ServiceProvider和ServiceUser都放入容器的过程，以后就由容器来提供ServiceUser的已完成依赖注入实例，
5 //其中用到的实例参数和类型参数一般是从配置档中读取的，这里是个简单的写法。
6 //所有的依赖注入方法都会有类似的容器初始化过程，本文在后面的小节中就不再重复这一段代码了。
7 Parameter[] finderParams = {new ConstantParameter("movies1.txt")};
8 pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
9 pico.registerComponentImplementation(MovieLister.class);
10 //至此，容器里面装入了两个类型，其中没给出构造参数的那一个（MovieLister）将依靠其在构造器中定义的传入参数类型，在容器中
11 //进行查找，找到一个类型匹配项即可进行构造初始化。
12 return pico;
13}
即使还没给出后面的代码，你也一定猜得到，这个container类一定有一个GetInstance(Type t)这样的方法，这个方法会为我们返回一个已经注入完毕的MovieLister。 一个简单的应用如下：
2{
3 MutablePicoContainer pico = configureContainer();
4 MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
5 Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
6 assertEquals("Once Upon a Time in the West", movies[0].getTitle());
7}
2.2 Setter Injection（设值注入）
这种注入方式和构造注入实在很类似，唯一的区别就是前者在构造函数的调用过程中进行注入，而它是通过给属性赋值来进行注入。无怪乎PicoContainer和Spring都是同时支持这两种注入方式。Spring对通过XML进行配置有比较好的支持，也使得Spring中更常使用设值注入的方式：
2 <bean id="MovieLister" class="spring.MovieLister">
3 <property name="finder">
4 <ref local="MovieFinder"/>
5 </property>
6 </bean>
7 <bean id="MovieFinder" class="spring.ColonMovieFinder">
8 <property name="filename">
9 <value>movies1.txt</value>
10 </property>
11 </bean>
12</beans>
下面也给出支持设值注入的容器参考实现，大家可以和构造器注入的容器对照起来看，里面的差别很小，主要的差别就在于，在获取对象实例（GetInstance）的时候，前者是通过反射得到待创建类型的构造器信息，然后根据构造器传入参数的类型在容器中进行查找，并构造出合适的实例；而后者是通过反射得到待创建类型的所有属性，然后根据属性的类型在容器中查找相应类型的实例。
1public static class Container
2{
3 private static Dictionary<Type, object> _stores = null;
4
5 private static Dictionary<Type, object> Stores
6 {
7 get
8 {
9 if (_stores == null)
10 _stores = new Dictionary<Type, object>();
11 return _stores;
12 }
13 }
14
15 public static object GetInstance(Type t)
16 {
17 if (Stores.ContainsKey(t))
18 {
19 if (Stores[t] == null)
20 {
21 object target = Activator.CreateInstance(t, false);
22 foreach (PropertyDescriptor pd in TypeDescriptor.GetProperties(target))
23 {
24 if (Stores.ContainsKey(pd.PropertyType))
25 //在此处为待创建实例设置属性，完成依赖注入过程。属性值是在容器中通过类型匹配的方式查找出来的。
26 pd.SetValue(target, GetInstance(pd.PropertyType));
27 }
28 return target;
29 }
30 else
31 return Stores[t];
32 }
33 return Activator.CreateInstance(t, false);
34 }
35
36 public static void RegisterImplement(Type t, object impl)
37 {
38 if (Stores.ContainsKey(t))
39 Stores[t] = impl;
40 else
41 Stores.Add(t, impl);
42 }
43
44 public static void RegisterImplement(Type t)
45 {
46 if (!Stores.ContainsKey(t))
47 Stores.Add(t, null);
48 }
49}
2.3 Interface Injection (接口注入)
这是笔者认为最不够优雅的一种依赖注入方式。要实现接口注入，首先ServiceProvider要给出一个接口定义：
2 void injectFinder(MovieFinder finder);
3}
接下来，ServiceUser必须实现这个接口：
2{
3 public void injectFinder(MovieFinder finder) {
4 this.finder = finder;
5 }
6}
容器所要做的，就是根据接口定义调用其中的inject方法完成注入过程，这里就不在赘述了，总的原理和上面两种依赖注入模式没有太多区别。
2.4 除了DI，还有Service Locator
上面提到的依赖注入只是消除ServiceUser和ServiceProvider之间的依赖关系的一种方法，还有另一种方法：服务定位器（Service Locator）。也就是说，由ServiceLocator来专门负责提供具体的ServiceProvider。当然，这样的话ServiceUser不仅要依赖于服务的接口，还依赖于ServiceContract。仍然是最早提到过的电影列举器的例子，如果使用Service Locator来解除依赖的话，整个依赖关系应当如下图所示：
图3
用起来也很简单，在一个适当的位置（比如在一组相关服务即将被调用之前）对ServiceLocator进行初始化，用到的时候就直接用ServiceLocator返回ServiceProvider实例：
2ServiceLocator locator = new ServiceLocator();
3locator.loadService("MovieFinder", new ColonMovieFinder("movies1.txt"));
4ServiceLocator.load(locator);
5//服务定义器的使用
6//其实这个使用方式体现了服务定位器和依赖注入模式的最大差别：ServiceUser需要显示的调用ServiceLocator，从而获取自己需要的服务对象；
7//而依赖注入则是隐式的由容器完成了这一切。
8MovieFinder finder = (MovieFinder) ServiceLocator.getService("MovieFinder");
9
正因为上面提到过的ServiceUser对ServiceLocator的依赖性，从提高模块的独立性（比如说，你可能把你构造的ServiceUser或者ServiceProvider给第三方使用）上来说，依赖注入可能更好一些，这恐怕也是为什么大多数的IOC框架都选用了DI的原因。ServiceLocator最大的优点可能在于实现起来非常简单，如果您开发的应用没有复杂到需要采用一个IOC框架的程度，也许您可以试着采用它。
3.广义的服务
文中很多地方提到服务使用者（ServiceUser）和服务提供者（ServiceProvider）的概念，这里的“服务”是一种非常广义的概念，在语法层面就是指最普通的依赖关系（类型A中有一个B类型的变量，则A依赖于B）。如果您把服务理解为WCF或者Web Service中的那种服务概念，您会发现上面所说的所有技术手段都是没有意义的。以WCF而论，其客户端和服务器端本就是依赖于Contract的松耦合关系，其实这也从另一个角度说明了SOA应用的优势所在。
688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
