Spring 最认同的技术是控制反转Inversion of Control（IoC）的依赖注入dependency injection（DI）模式。控制反转是一个通用的概念，它可以用许多不同的方式去表达，依赖注入仅仅是控制反转的一个具体的例子。
依赖注入（Dependency Injection）
- 作用：
当编写一个复杂的Java程序时，应该让这个程序尽可能独立于其他的Java类来增加这些类的可重用性。这样一来，进行单元测试的时候，也可以使它们独立于其他类进行测试。
Dependency Injection有助于将这些类粘合在一起，并且在同一时间让它们保持独立。
- 依赖：
在Class A中有Class B的实例，则称Class A对Class B有一个依赖。例如：
Class Human中有Class Father，则称类Human对类Father有一个依赖。
上一段代码中存在的问题：
（1）如果现在要改变father的生成方式，如果需要用new Father(String name)初始化father， 则要改变Human的代码。 （2）如果想测试不同的Father对象对Human的影响很困难，因为father的初始化被写死在了Human的构造函数中。 （3）如果new Father()的过程非常缓慢，单测时我们希望用已经初始化好的father对象Mock掉这个过程也会很困哪。
- 依赖注入：
在上一例中，将依赖在构造函数中直接初始化是一种Hard Init方式，这种方式的弊端在于两个类不够独立，不方便测试。 当然我们还有另外一种Init方式，例如：
在这种方式中，我们将father对象作为构造函数的一个参数传入。这样，在调用Human的构造方法之前，需要外部初始化好一个Father对象。像这种非自己主动初始化依赖，而是通过外部来传入依赖的方式被称之为依赖注入。
依赖注入的好处在于：
（1）将依赖之间解耦
（2）因为已经解耦，所以方便做单元测试，尤其是Mock测试。
- Java中的依赖注入
实现依赖注入有很多种方式，在Java中，最常使用的方式是通过注解来实现。通过在字段的声明前添加@Inject注解进行标记，来实现依赖对象的自动注入。例如：
但是实际上，如果只写了一个@Inject注解，Father对象并不会被自动注入，因为它还需要依赖一个注入框架，比如Spring。
控制反转
为了更好的理解控制反转的作用，让我们看一个现实生活中的例子。某公司作为一个电器制造商需要把自己的商品分销到全球各地。经过研究他们发现，不同的分销渠道有不同的规则，于是他们派出了不同的销售代表来执行不同的规则。 后来，销售渠道越来越多，他们发现，每增加一个销售渠道就要新增一批人和一个新的流程，因为每个渠道都依赖于（耦合）它相应的规则。
后来，系统过于庞大，于是他们决定制定业务标准，开发分销信息化系统，只有符合这个标准的渠道商才能成为该公司的分销商。这样，分销的过程就由先前的该公司适应分销商，变成了分销商反过来依赖自己的标准，反转了控制，倒置了依赖。
如果我们把该公司和各分销商当做软件工程中的对象，那么该公司开发的分销信息化系统则被称为IoC容器。在没有引入分销信息化系统（IoC容器）之前，分销商就想齿轮一样，增加一个齿轮就要增加多钟依赖在其他齿轮上，最终的结果就是导致 系统越来越复杂。而引入分销系统后，各分销商只依赖于分销系统，可以很方便的增加和删除齿轮。
在一个软件系统中，各对象就像齿轮一样，是相互耦合协同工作的。在一个强耦合的系统中，如果一个零件不能正常工作了，整个系统就崩溃了。然而，对象之间的耦合关系是不可避免的也是非常必要的，这是协同工作的基础。 随着应用系统规模的庞大，对象之间的依赖关系也变得越来越复杂，经常会出现对象之间存在多重依赖的关系。
为了解决对象间耦合度过高的问题，控制反转的理论就应运而生了。它被设计来实现对象之间的解耦。控制反转是一种面向对象的设计原则，它的基本思想是：借助于”第三方”实现具有依赖关系的对象之间的解耦。
由”第三方”（IoC容器）来代替强耦合的各个齿轮。这样，情况就由之前的齿轮间的依赖转换成了齿轮与”第三方”的依赖，每一个齿轮都依赖”第三方”，但是齿轮与齿轮之间是独立的。在这里IoC容器起到了”粘合剂”的作用，把系统中的 所有对象粘合在了一起。
在引入IoC容器前，如果对象A依赖于对象B，那么对象A在初始化或者运行的过程中，需自己主动去创建对象B或使用已经被创建的对象B。但是无论是创建还是使用，控制权都在A手上。 而在引入IoC容器之后，情况完全改变了，由于IoC容器的加入，对象A与对象B之间失去了直接的联系， 所以，当对象A需要用到对象B的时候，IoC容器会主动创建一个对象B注入到对象A需要的地方。 在后者中，对象A获得依赖对象B的过程，由一个主动行为变成了一个被动行为，控制权颠倒了过来，所以这个过程被称为”控制反转”。
控制反转和依赖注入的关系
简单的说，控制反转是一种思想，依赖注入是一种设计模式。
IoC框架用依赖注入来实现控制反转。当然控制反转还有其他的实现方式，所以，不能讲控制反转等同于依赖注入。
Spring中的依赖注入
让我们看一下这个例子：
在这里我们先定义了两个类，它们都使用了依赖注入的方式从外部传入依赖，而不是自己创建依赖。问题是，谁创建了finder和filename，并把finder传给了MovieLister，把filename传给了ColonMovieFinder？答案是：Spring IoC容器。 对象的依赖由对象的构造函数的参数、工厂方法的参数和属性来定义，然后由Spring IoC容器在创建bean的时候将依赖注入对象。
Spring IoC的基础包是：org.springframework.beans 和 org.springframework.context
BeanFactory接口就是所谓的Spring IoC容器，它可以管理任何类型的对象。ApplicationContext是BeanFactory的子接口，它添加了更丰富的特性。Spring IoC容器通过读取配置文件来实例化bean并装配bean之间的依赖关系。一旦Spring IoC容器的初始化完成，我们就可以使用它来管理所有的bean了。 Spring中的bean是指被Spring IoC容器管理的各种对象，bean由Spring IoC容器负责实例化、装配、管理，bean本身以及bean之间的互相依赖由配置元数据定义。配置元数据也就是Spring的配置文件，它的作用是告诉Spring IoC容器应该如何实例化、装配和管理bean。
配置文件可以通过xml、java代码和注解等形式来进行定义。
假设我们有如下一个bean：
- 基于xml方式来定义bean，需要在services.xml中写入：
其中bean id是这个bean的唯一标识，可以用这个id在其他bean中引用这个bean，而class用来指定该bean的全类名。
- 基于java代码和注解的 bean 定义：
在这里，我们使用@Configuration注解来定义配置类，使用@Bean注解来定义bean，使用@Bean的name属性来定义bean id
实例化Spring IoC容器非常简单，只需要告诉Spring IoC容器配置文件的位置即可。
- 实例化基于xml配置的Spring IoC容器：
- 实例化基于java代码和注解配置的Spring IoC容器：
同样，我们可以从Spring IoC容器中获取bean：
通过上面这个简单的例子我们明白了Spring IoC的配置过程，当然，我个人认为，上面这个简单的例子是没有必要使用bean来返回实例的，可以简单的初始化一个实例，达到的效果和使用IoC容器管理几乎是一样的（如果你不需要单例模式）。
真正需要Spring IoC来进行管理的是像段首这样有依赖的类。回到段首我们举的MovieLister和ColonMovieFinder的例子中，我们同样可以使用xml和代码注解两种方式配置这个IoC容器。xml配置的方式如下：
每个bean代表一个对象的实例（默认是Singleton模式，即在程序的生命周期内，所有的对象都只有一个实例，进行重复使用），通过配置bean，IoC容器在启动的时候会根据配置生成bean实例。这里Spring IoC容器会根据配置创建MovieFinder， 在运行的时候把MovieFinder赋值给MovieLister的finder属性，完成依赖注入的过程。
在对这段代码进行测试时，需要首先根据配置生成Spring IoC容器（既：ApplicationContext），然后从容器中获取MovieLister的实例。
具体配置语法请参考Spring Documentation的Dependencies章节。