Ioc 容器之 ApplicationContext

文章开始声明，该篇文章主要是讲IOC容器的ApplicationContext 相比 BeanFactory的区别，IOC整体思想都是一致的，那么ApplicationContext 有哪些自己的特性呢？

Spring为基本的BeanFactory类型容器提供了XmlBeanFactory实现。相应地，它也为Applica- tionContext类型容器提供了以下几个常用的实现。 

org.springframework.context.support.FileSystemXmlApplicationContext。在默认情况下，从文件系统加载bean定义以及相关资源的ApplicationContext实现。

org.springframework.context.support.ClassPathXmlApplicationContext。在默认情况下，从Classpath加载bean定义以及相关资源的ApplicationContext实现。

org.springframework.web.context.support.XmlWebApplicationContext。Spring提供的用于Web应用程序的ApplicationContext实现

下面主要围绕ApplicationContext 较之BeanFactory特有的一些特性展开讨论，即国际化（I18n）信息支持、统一资源加载策略以及容 器内事件发布等。 

统一资源加载策略

为什么要有资源加载策略：

从Java SE提供的标准类java.net.URL。URL全名是Uniform Resource Locator（统一资源定位器），基本实现却只限于网络形式发布的资源的查找和定位工作，基本上 只提供了基于HTTP、FTP、File等协议（sun.net.www.protocol包下所支持的协议）的资源定位功能。 但是，资源可以任何形式存在，如以二进制对象形式存在、以字节流形式存在、以文件形 式存在等；而且，资源也可以存在于任何场所，如存在于文件系统、存在于Java应用的Classpath中， 甚至存在于URL可以定位的地方。资源查找后返回的形式多种多样，没有一个统一的抽象。理想情况下，资源查找 完成后，返回给客户端的应该是一个统一的资源抽象接口，客户端要对资源进行什么样的处理，应该 由资源抽象接口来界定，而不应该成为资源的定位者和查找者同时要关心的事情。，在这个前提下① ，Spring提出了一套基于org.springframework.core.io.Resource和 org.springframework.core.io.ResourceLoader接口的资源抽象和加载策略。 

Spring 框架内部使用org.springframework.core.io.Resource接口作为所有资源的抽象和访 问接口。

 该接口定义了7个方法，可以帮助我们查询资源状态、访问资源内容，甚至根据当前资源创建新 的相对资源。不过，要真想实现自定义的Resource，倒是真没必要直接实现该接口，我们可以继承 org.springframework.core.io.AbstractResource抽象类，然后根据当前具体资源特征，覆盖相 应的方法就可以了。

任何的ApplicationContext实现都可以看作是一个 ResourceLoader甚至ResourcePatternResolver。而这就是ApplicationContext支持Spring内统一 资源加载策略的真相。 通常，所有的ApplicationContext实现类会直接或者间接地继承org.springframework. context.support.AbstractApplicationContext，从这个类上，我们就可以看到Application- Context与ResourceLoader之间的所有关系。

为ResourceLoader或者ResourcePatternResolver的Applica- tionContext，到底因此拥有了何等神通[统一资源加载给ApplicationContext带来什么好处？]

1 扮演ResourceLoader的角色 ----- 既然ApplicationContext可以作为ResourceLoader或者ResourcePatternResolver来使用， 那么，很显然，我们可以通过ApplicationContext来加载任何Spring支持的Resource类型。

2  ResourceLoader类型的注入 ------  在大部分情况下，如果某个bean需要依赖于ResourceLoader来查找定位资源，我们可以为其注 入容器中声明的某个具体的ResourceLoader实现，该bean也无需实现任何接口，直接通过构造方法 注入或者setter方法注入规则声明依赖即可，这样处理是比较合理的。不过，如果你不介意你的bean定 义依赖于Spring的API，那不妨考虑用一下Spring提供的便利。

3   Resource类型的注入  ----- 我们之前讲过，容器可以将bean定义文件中的字符串形式表达的信息，正确地转换成具体对象定 义的依赖类型。对于那些Spring容器提供的默认的PropertyEditors无法识别的对象类型，我们可以 提供自定义的PropertyEditor实现并注册到容器中，以供容器做类型转换的时候使用。默认情况下， BeanFactory容器不会为org.springframework.core.io.Resource类型提供相应的Property- Editor，所以，如果我们想注入Resource类型的bean定义，就需要注册自定义的PropertyEditor到 BeanFactory容器。不过，对于ApplicationContext来说，我们无需这么做，因为Application- Context容器可以正确识别Resource类型并转换后注入相关对象。 

国际化信息支持 

对于Java中的国际化信息处理，主要涉及两个类，即java.util.Locale和java.util.ResourceBundle。不同的Locale代表不同的国家和地区，每个国家和地区在Locale这里都有相应的简写代码表示， 包括语言代码以及国家代码，这些代码是ISO标准代码。如，Locale.CHINA代表中国，它的代码表示 为zh_CN；Locale.US代表美国地区。ResourceBundle用来保存特定于某个Locale的信息（可以是String类型信息，也可以是任何类型 的对象）。Spring在Java SE的国际化支持的基础上，进一步抽象了国际化信息的访问接口，也就是 org.springframework.context.MessageSource。现在我们知道，ApplicationContext除了实现了ResourceLoader以支持统一的资源加载，它还 实现了MessageSource接口，那么就跟ApplicationContext因为实现了ResourceLoader而可以当作 ResourceLoader来使用一样，ApplicationContext现在也是一个MessageSource了。 

容器内部事件发布

Spring的ApplicationContext容器提供的容器内事件发布功能，是通过提供一套基于Java SE标 准自定义事件类而实现。Spring 的 ApplicationContext 容器内部允许以org.springframework.context.Appli- cationEvent的形式发布事件，容器内注册的org.springframework.context.Application- Listener类型的bean定义会被ApplicationContext容器自动识别，它们负责监容器内发布的所有 ApplicationEvent类型的事件。也就是说，一旦容器内发布ApplicationEvent及其子类型的事件， 注册到容器的ApplicationListener就会对这些事件进行处理。 

多配置模块加载的简化 

实际上，这也不算ApplicationContext比较突出的特色功能，只是相对于BeanFactory来说， 在这一点上做得更好罢了。 6 我们知道，在使用Spring的IoC轻量级容器进行实际开发的过程中，为了避免出现整个团队因某个 资源独占而无法并行、高效地完成工作等问题，通常会将整个系统的配置信息按照某种关注点进行分 割，使得关注点逻辑良好地划分到不同的配置文件中，如按照功能模块或者按照系统划分的层次等。 这样，在加载整个系统的bean定义时，就需要让容器同时读入划分到不同配置文件的信息。相对于 BeanFactory来说，ApplicationContext大大简化了这种情况下的多配置文件的加载工作。