Spring揭秘-3.IOC Service Provider

概念

虽然业务对象可以通过IoC方式声明相应的依赖，但最终仍需要通过某种角色或者服务这些相互依赖的对象绑定在一起，而IoC Service Provider 就对应IoC场景中的这一角色。
IoC Service Provider 在这里是一个抽象出来的概念，它可以指代任何将IoC场景中的业务对象绑定到一起的实现方式，它可以是一段代码，也可以是一组相关的类，甚至可以是比较通用的IoC框架或者IoC容器实现。

IoC Service Provider 的职责

IoC Service Provider 的职责相对于来说比较简单，主要有两个：业务对象的构建管理和业务对象间的依赖绑定。
1. 业务对象的构建管理。在IoC场景中，业务对象无需关心所依赖的对象如何构建如何取得，但这部分工作始终需要有人来做。所以，IoC Service Provider 需要将对象的构建逻辑从客户端对象那里剥离出来，以免这部分逻辑污染对象的是实现。
2. 业务对象间的依赖绑定。对于IoC Service Provider来说，这个职责是最艰难也是最重要的，这是它的最终使命所在。如果不能完场这个职责，那么，无论业务对象如何的“呼喊”，也不会得到依赖对象的任何回应（最常见的倒是会收到一个NullPointerException）。IoC Service Provider 通过结合之前构建和管理的所有业务对象，以及各个业务对象间可以识别的依赖关系，将这些对象依赖的对象注入绑定，从而保证每个业务对象在使用的时候，可以处于就绪状态。
总结也就是说：IoC Service Provider干的工作就是 一 构建依赖对象， 二 将对象向 IoC Service Provider 要对象时 提供对象的依赖注入。

IoC Service Provider 是如何管理对象间的依赖关系

1.直接编码方式

当大部分的IoC容器支持直接编码的方式，在容器启动之前，我们可以通过程序编码的方式将被注入对象和依赖对象注册到容器中，并明确它们相互之间的依赖注入关系。

通过直接编码的形式管理基于接口注入的依赖注入关系：

通过bind方法将“被注入对象”（由IFXnewsListenerCallable接口添加标志）所依赖的对象，绑定为容器中注册过的IFXNewsListener类型的对象实例。容器在返回FXNewsProvider对象实例之前，会根据这个绑定信息，将IFXNewsListener注册到容器中的对象实例注入到“被注入对象”–FXNewsProvider中，并最终返回已经组装完毕的FXNewsProvider对象。
所以，通过程序编码让最终的IoC Service Provider (也就是各个IoC框架或者容器实现)得以知晓服务的“奥义”，应该是管理依赖绑定关系的最基本方式。

解释: 这里将IFXnewsListenerCallable接口注入到 相应的 IFXNewsListener() 中 在实例化IFXNewsListener 时会将这个IFXnewsListenerCallable标志 实例。
最终在实例化FXNewsProvider 时 会将 IFXNewsListener 实例化，然后IFXNewsListener将IFXnewsListenerCallable实例化 这里 具体如何实例化的我们存疑

2. 配置文件方式

这是一种普遍的依赖注入方式。像普通文本文件，properties文件、XML文件等可以成为管理依赖注入关系的载体。不过，最为常见的，还是通过XML文件来管理对象注册和对象间的依赖关系，比如Spring IoC 容器和PicContainer基础等，都是采用XML文件来管理和保存依赖注入信息的。对于我们例子中的FXNewsProvider来说，也可以通过Spring配置文件的方式来配置和管理各个对象间的依赖关系。

我们可以像代码清单一样，通过“newsProvider” 这个名字中取得已经转好的FXNewsProvider并使用。

3. 元数据方式

当然，注解最终也是要通过代码处理来确定最终的注入关系，从这里来说，注解可以算编码方式的一种特殊情况了。