目录
loC Service Provider如何管理对象间的 依赖关系
@Autowired之外的选择 使用JSR250标注依赖注入关系
将革命进行得更彻底一些( classpath-scanning功能介绍）
loC的基本概念
简介
IoC是随着近年来轻量级容器(Lightweight Container)的兴起而逐渐被很多人提起的一个名词，它 的全称为Inversion of Control, 中文通常翻译为“控制反转＂，它还有一个别名叫做依赖注入(Dependency Injection)。好莱坞原则"Don't call us, we will call you." Q)恰如其分地表达了“反转＂的意味，是用 来形容IoC最多的一句话。
注意 本章更多的是将IoC和依赖注入看作等同的概念进行讲解。但是，在这一点上可能存在 不同的观点，比如Expert Spring MVC and Web Flow和Expert One-on-One J2EE without EJB等书 中都将依赖注入看作是IoC的一种方式。可以暂且忽略这些观点，将IoC和依赖注入等同 看待。理解了依赖注入之后，可以再结合其他资料对IoC做进一步的研究。
为了更好地阐述IoC模式的概念，我们引入以下简单场景。
在我经历的FX项目＠中，经常需要近乎实时地为客户提供外汇新闻。通常情况下，都是先从不同 的新闻社订阅新闻来源，然后通过批处理程序定时地到指定的新闻服务器抓取最新的外汇新闻，接着 将这些新闻存入本地数据库，最后在FX系统的前台界面显示。
假设我们有一个FXNewsProvider类来做以上工作，其代码如代码清单
其中，FNewsProvider需要依赖IFXNewsLis七ener来帮助抓取新闻内容，并依赖IFXNewsPersister存储抓取的新闻。
假设默认使用道琼斯(Dow Jones)新闻社的新闻，那么我们相应地提供了DowJonesNewsListener和DowJonesNewsPersister两两个实现。通常情况下，需要在构造函数中构造IFXNewsProvider 依赖的这两个类（以下将这种被其他类依赖的类或对象，简称为“依赖类”、 “依赖对象")'如代 码清单
看，这就是我们通常的做事方式！如果我们依赖于某个类或服务，最简单而有效的方式就是直接 在类的构造函数中新建相应的依赖类。这就好比要装修新房，需要用家具，这个时候，根据通常解决 对象依赖关系的做法，我们就会直接打造出需要的家具来。不过，通常都是分工明确的，所以，大多 数情况下，我们可以去家具广场将家具买回来，然后根据需要装修布置即可。
不管是直接打造家具（通过new构造对象），还是去家具广场买家具（或许是通过ServiceLocator解决直接的依赖耦合），有一个共同点需要我们关注，那就是，我们都是自己主动地去获 取依赖的对象！
可是回头想想，我们自己每次用到什么依赖对象都要主动地去获取，这是否真的必要？我们最终 所要做的，其实就是直接调用依赖对象所提供的某项服务而已。只要用到这个依赖对象的时候，它能 够准备就绪，我们完全可以不管这个对象是自己找来的还是别人送过来的。对于FXNewsProvider来 说，那就是在getAndPersistNews()方法调用newsListener的相应方法时，newsListener能够准 备就绪就可以了。如果有人能够在我们需要时将某个依赖对象送过来，为什么还要大费周折地自己去 折腾？
实际上，IoC就是为了帮助我们避免之前的“大费周折”，而提供了更加轻松简洁的方式。它的 反转，就反转在让你从原来的事必躬亲，转变为现在的享受服务。你想啊，原来还得鞍马劳顿，什么东西都得自己去拿。现在是用什么，让别人直接送过来就成。所以，简单点儿说，IoC的理念就是， 让别人为你服务！在图中，也就是让IoC Service Provider来为你服务！
通常情况下，被注入对象会直接依赖于被依赖对象。但是，在IoC的场景中，二者之间通过IoC Service Provider来打交道，所有的被注入对象和依赖对象现在由IoC Service Provider统一管理。被注入对象需要 什么，直接跟IoC Service Provider招呼一声，后者就会把相应的被依赖对象注入到被注入对象中，从而 达到IoC Service Provider为被注入对象服务的目的。
IoC Service Provider在这里就是通常的IoC容器所充 当的角色。从被注入对象的角度看，与之前直接寻求依赖对象相比，依赖对象的取得方式发生了反转， 控制也从被注入对象转到了IoC Service Provider那里.
其实IoC就这么简单！原来是需要什么东西自己去拿，现在是需要什么东西就让别人送过来。图 以两种场景，形象地说明了使用IoC模式前后的差别。
出门之前得先穿件外套吧？以前，你得自己跑到衣柜前面取出衣服这一依赖对象，然后自己穿上 再出门。而现在，你只要跟你的“另—半“使个眼色或说一旬"Honey, 衣服拿来。”她就会心领神 会地到衣柜那里为你取出衣服，然后再给你穿上。现在，你就可以出门了。 （此时此刻，你心里肯定 窃喜， “有人照顾的感觉真好! )对你来说，到底哪种场景比较恓意，我想已经不言自明了吧？
如何注入对象
＂伙计，来杯啤酒！”当你来到酒吧，想要喝杯啤酒的时候，通常会直接招呼服务生，让他为你 送来一杯清凉解渴的啤酒。同样地，作为被注入对象，要想让IoC Service Provider为其提供服务，并 将所需要的被依赖对象送过来，也需要通过某种方式通知对方。
- 如果你是酒吧的常客，或许你刚坐好，服务生已经将你最常喝的啤酒放到了你面前；
- 如果你是初次或偶尔光顾，也许你坐下之后还要招呼服务生， "Waiter,Tsingdao, please." ;
- 还有一种可能，你根本就不知道哪个牌子是哪个牌子，这时，你只能打手势或干脆画出商标 图来告诉服务生你到底想要什么了吧！
不管怎样，你终究会找到一种方式来向服务生表达你的需求，以便他为你提供适当的服务。那么， 在IoC模式中，被注入对象又是通过哪些方式来通知IoC Service Provider为其提供适当服务的呢？
IoC模式最权威的总结和解释，应该是Martin Fowler的那篇文章"Inversion of Control Containers and the Dependency Injection pattern" , 其中提到了三种依赖注入的方式，即构造方法注入(constructor 叨ection)、setter方法注入(setter injection)以及接口注入(interface injection)。下面让我们详细看 一下这三种方式的特点及其相互之间的差别。
构造方法注入
顾名思义，构造方法注入，就是被注入对象可以通过在其构造方法中声明依赖对象的参数列表， 让外部（通常是IoC容器）知道它需要哪些依赖对象。对于前面例子中的FXNewsProvider来说，只要 声明如下构造方法（见代码清单)即可支持构造方法注入。
IoC Service Provider会检查被注入对象的构造方法，取得它所需要的依赖对象列表，进而为其注 入相应的对象。同一个对象是不可能被构造两次的，因此，被注入对象的构造乃至其整个生命周期， 应该是由IoC Service Provider来管理的。
构造方法注入方式比较直观，对象被构造完成后，即进入就绪状态，可以马上使用。这就好比你 刚进酒吧的门，服务生已经将你喜欢的啤酒摆上了桌面一样。坐下就可马上享受一份清凉与恨意。
setter方法注入
对于JavaBean对象来说，通常会通过setXXX ()和getXXX()方法来访问对应属性。这些setXXX()方 法统称为setter方法，getXXX()当然就称为getter方法。通过setter方法，可以更改相应的对象属性，通 过getter方法，可以获得相应属性的状态。
所以，当前对象只要为其依赖对象所对应的属性添加setter 方法，就可以通过setter方法将相应的依赖对象设置到被注入对象中。以FXNewsProvider为例，添加 setter方法后如代码清单所示。
这样，外界就可以通过调用setNewsListener和setNewPersistener方法为FXNewsProvider对 象注入所依赖的对象了。
setter方法注入虽不像构造方法注入那样，让对象构造完成后即可使用，但相对来说更宽松一些， 可以在对象构造完成后再注入。这就好比你可以到酒吧坐下后再决定要点什么啤酒，可以要百威，也 可以要大雪，随意性比较强。如果你不急着喝，这种方式当然是最适合你的。
接口注入
相对于前两种注入方式来说，接口注入没有那么简单明了。被注入对象如果想要IoC Service Provider为其注入依赖对象，就必须实现某个接口。这个接口提供一个方法，用来为其注入依赖对象。 IoC Service Provider最终通过这些接口来了解应该为被注入对象注入什么依赖对象。图演示了如何 使用接口注入为FXNewsProvider注入依赖对象。
FXNewsProvider为了让IoC Se
最低0.47元/天 解锁文章
3836
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
