IoC 其实有两种方式,一种就是 DI,而另一种是 DL,即 Dependency Lookup(依赖查找),前者是当前软件实体被动接受其依赖的其他组件被 IoC 容器注入,而后者则是当前软件实体主动去某个服务注册地查找其依赖的那些服务
public class App {
public static void main(String[] args) {
ApplicationContext context = new FileSystemXmlApplication-Context("...");
// ...
MockService service = context.getBean(MockService.class);
service.doSomething();
}
}
任何一个使用 Spring 框架构建的独立的 Java 应用(Standalone Java Application),通常都会存在一行类似于“context.getBean(..);”的代码。
实际上,这行代码做的就是 DL 的工作,而构建的任何一种 IoC 容器背后(比如 BeanFactory 或者 ApplicationContext)发生的事情,则更多是 DI 的过程
1)收集和注册
第一个阶段可以认为是构建和收集 bean 定义的阶段,在这个阶段中,我们可以通过 XML 或者 Java 代码的方式定义一些 bean,然后通过手动组装或者让容器基于某些机制自动扫描的形式,将这些 bean 定义收集到 IoC 容器中。
假设我们以 XML 配置的形式来收集并注册单一 bean,一般形式如下:
<bean id="mockService" class="..MockServiceImpl"> ...</bean>
如果嫌逐个收集 bean 定义麻烦,想批量地收集并注册到 IoC 容器中,我们也可以通过 XML Schema 形式的配置进行批量扫描并采集和注册:
<context:component-scan base-package="com.keevol">
2)分析和组装
当第一阶段工作完成后,我们可以先暂且认为 IoC 容器中充斥着一个个独立的 bean,它们之间没有任何关系。
但实际上,它们之间是有依赖关系的,如果 IoC 容器发现某个 bean 依赖另一个 bean,它就会将这另一个 bean 注入给依赖它的那个 bean,直到所有 bean 的依赖都注入完成,所有 bean 都“整装待发”,整个 IoC 容器的工作即算完成。
至于分析和组装的依据,Spring 框架最早是通过 XML 配置文件的形式来描述 bean 与 bean 之间的关系的,随着 Java 业界研发技术和理念的转变,基于 Java 代码和 Annotation 元信息的描述方式也日渐兴盛(比如 @Autowired 和 @Inject),但不管使用哪种方式,都只是为了简化绑定逻辑描述的各种“表象”,最终都是为本阶段的最终目的服务。