Spring IOC BeanFactory(译)

BeanFactory仅仅是为Spring IOC提供下层的基础功能,它仅仅是用来集成其它第三方框架。在Spring中使用的底层大量特性都是基于BeanFactory。BeanFactory与其相关接口,例如BeanFactoryAware,InitializingBean,DisposableBean做为底层组件用来大量的第三方框架与Spring集成。为了兼容JDK1.4或者避免依赖JSR-250,第三方组件不能够使用更加现代的equivalents，例如@PostConstruct或者@PreDestroy.

这个章节提供额外的内容去描述BeanFactory与ApplicationContext的不同以及如何直接IOC容器去查询典型的singleton使用.

1、BeanFactory or ApplicationContext?

当我们在开发应用的时候,选择BeanFactory还是ApplicationContext.推荐你使用ApplicationContext,除非你有不使用它的理由。

因为Application包含BeanFactory的所有功能,一般它被建议度要高于BeanFactory。除非一些特殊的情况,例如运行在资源受限的嵌入式应用设备上。它的内存卡使用是非常苛刻的，一些额外的千字节可能会出现。但是对于绝大多数典型的企业级应用与系统，Application是你的不二之选。Spring使用了大量的BeanPostProcessor扩展点(proxy等等)。如果你仅仅使用简单的BeanFactory。如果你不使用额外的步骤不会支持transaction与AOP这些功能。这种情况可能有点模糊不清，因为没有真实不正确的配置。

下面的表格列举了BeanFactory与ApplicationContext接口与实现类提供的特性。

Table . Feature Matrix

Feature BeanFactory ApplicationContext Bean instantiation/wiring YES YES BeanPostProcessor自动注册 NO YES BeanFactoryPostProcessor自动注册 NO YES 方便的MessageSource使用(i18n) NO YES ApplicationEvent发布 NO YES

---

使用BeanFactory实现明确的注册一个BeanPostProcessor类型的Bean，你需要像下面的代码:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();// populate the factory with bean definitions// now register any needed BeanPostProcessor instancesMyBeanPostProcessor postProcessor = new MyBeanPostProcessor();factory.addBeanPostProcessor(postProcessor);// now start using the factory

使用BeanFactory实现明确的注册一个BeanFactoryPostProcessor类型的Bean，你需要像下面的代码:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));// bring in some property values from a Properties filePropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();cfg.setLocation(new FileSystemResource("jdbc.properties"));// now actually do the replacementcfg.postProcessBeanFactory(factory);

上面的两种情况,明确的注册步骤是很不方便的。这也是大多数使用基于Spring构建的应用优先考虑使用ApplicationContext实现而不是使用BeanFactory实现,特别是在使用BeanFactoryPostProcessors与BeanPostProcessors的情况下。这些机制实现包含了重要的功能特性,例如占位符替换和AOP。

2、Glue code and the evil singleton

在写应用代码的时候使用Spring IoC容器依赖注入的方式。当容器创建的时候就会提供依赖，并且完全感知不到容器的存在。当你代码分层的时候这层代码需要依赖另外一层的代码,这个时候时候需要使用Spring IOC容器提供的singleton(or quasi-singleton).例如，如果没有Spring IOC提供的获取这些对象的能力,第三方法代码可能会直接创建的对象(Class.forName()style).如果由第三方代码构造对象是small stub或代理,然后使用一个单例风格访问Spring IoC容器实际对象来代理,然后控制反转仍实现了大部分的代码(对象的容器)。因此大多数代码仍然没有意识到容器或它是如何访问,仍然与其他代码解耦,随之而来的好处。EJB可能也使用这个stub/proxy方法委托给一个普通的Java实现对象,然后从Spring IoC容器检索。虽然Spring IoC容器本身理念不必是一个单例,它可能是不切实际的内存使用或初始化时间(当使用Spring IoC容器中的bean,如Hibernate SessionFactory)为每个bean使用自己的non-singleton的Spring IoC容器。

查找服务定位器的应用程序上下文访问共享的spring管理的风格有时是唯一的选择组件,如在EJB 2.1环境下,或在war文件中当你想共享一个ApplicationContext作为WebApplicationContexts的父容器。在这种情况下,你应该考虑使用的公共设施程序类ContextSingletonBeanFactoryLocator定位器中。在spring团队的blog当中有相应的描述。

因为水平有限，翻译不足之处还望见谅。
原文地址:spring-framework-reference-4.2.6.RELEASE