Spring 使用已经有些年头了,但始终没有静下心来整理 Spring,关于 Spring 各种实现方式也都是大而概之的了解,也没有深入的研究。今天终于鼓起勇气来整理他了。
万事开头难,从哪里开始呢,那就从常用的 Factory 开始吧。
在日常的使用中,比较少的直接使用 BeanFactory,常用是 ApplicationContext 接口。下面我们就以FileSystemXmlApplicationContext 为例,开始梳理 Spring 中的依赖注入的知识。
首先看看 FileSystemXmlApplicationContext 实现了那些接口、继承了那些基类:
上图可以说明 FileSystemXmlApplicationContext 是一个具有完整功能的 BeanFactory,直接可以被客户使用。可以把它分为两部分接口的体现,一方面是 BeanFactory ,另一方面是 ResourceLoader 。前者使其具体 Factory 的相关功能,后者使其具体资源加载的功能。我们在日常中常用的 ApplicationConext 接口是继承与 BeanFactory 的,FileSystemXmlApplicationContext 也实现了这个接口。
下面我们分析一下其构造器源码:
// 默认构造器
public FileSystemXmlApplicationContext() {
}
// 指定了父容器的构造器
public FileSystemXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
// 指定单个的配置文件位置构造器
public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[] {configLocation}, true, null);
}
// 指定多个配置文件位置构造器,默认需要刷新容器
public FileSystemXmlApplicationContext(String... configLocations) throws BeansException {
this(configLocations, true, null);
}
// 指定了配置文件和父容器的构造器,默认需要刷新容器
public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException {
this(configLocations, true, parent);
}
// 指定了配置文件位置以及是否需要刷新的构造器
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh) throws BeansException {
this(configLocations, refresh, null);
}
// 核心构造器,设置了Bean配置文件位置、是否需要刷新容器、父容器的构造器
// 如果配置了需刷新容器,则调用刷新接口。
// refresh方法是由AbstractApplicationContext提供,后面的笔记中应该相信说明这方法(后续附上链接)
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
throws BeansException {
super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}
FileSystemXmlApplicationContext 定义是很简单,他其中关于 Bean 的资源查找、解析、注册都有其父类完成。
Spring 中关于资源的查找是很大一部分内容,这部分功能大部分是依赖 DefaultResourceLoader 的实现,下次主要说明 Spring 是如何加载资源文件的。