Spring 框架
API
Spring 框架
API

1.16. TheBeanFactory API

预计阅读时间: 8 分钟

The BeanFactory API provides the underlying basis for Spring’s IoC functionality. Its specific contracts are mostly used in integration with other parts of Spring and related third-party frameworks, and its DefaultListableBeanFactory implementation is a key delegate within the higher-level GenericApplicationContext container. The BeanFactory API provides the underlying basis for Spring’s IoC functionality. Its specific contracts are mostly used in integration with other parts of Spring and related third-party frameworks, and its DefaultListableBeanFactory implementation is a key delegate within the higher-level GenericApplicationContext container. BeanFactory API 为 Spring 的 IoC 功能提供底层基础。其具体合约主要在与其他 Spring 和相关第三方框架的集成中使用，其DefaultListableBeanFactory 实现是高级GenericApplicationContext容器中的关键代表。

BeanFactory and related interfaces (such as BeanFactoryAware, InitializingBean, DisposableBean) are important integration points for other framework components. By not requiring any annotations or even reflection, they allow for very efficient interaction between the container and its components. BeanFactory 以及相关接口（如 BeanFactoryAware 、 InitializingBean 、 DisposableBean ）是其他框架组件的重要集成点。它们不需要任何注解甚至反射，允许容器与其组件之间非常高效的交互。 Application-level beans may use the same callback interfaces but typically prefer declarative dependency injection instead, either through annotations or through programmatic configuration. 应用级别的 bean 可能使用相同的回调接口，但通常更喜欢使用声明式依赖注入，无论是通过注解还是通过程序配置。

Note that the core BeanFactory API level and its DefaultListableBeanFactory implementation do not make assumptions about the configuration format or any component annotations to be used. All of these flavors come in through extensions (such as XmlBeanDefinitionReader and AutowiredAnnotationBeanPostProcessor) and operate on shared BeanDefinition objects as a core metadata representation. This is the essence of what makes Spring’s container so flexible and extensible. 请注意，核心 BeanFactory API 级别及其 DefaultListableBeanFactory 实现不假设配置格式或任何要使用的组件注解。所有这些风味都通过扩展（如 XmlBeanDefinitionReader 和 AutowiredAnnotationBeanPostProcessor ）传入，并在共享 BeanDefinition 对象上作为核心元数据表示进行操作。这就是使 Spring 容器如此灵活和可扩展的本质。

(#context-introduction-ctx-vs-beanfactory)1.16.1.BeanFactory orApplicationContext?

1.16.1. BeanFactory 或 ApplicationContext ？

This section explains the differences between the BeanFactory and ApplicationContext container levels and the implications on bootstrapping. 本节解释了 BeanFactory 和 ApplicationContext 容器级别之间的差异及其对启动的影响。

You should use an ApplicationContext unless you have a good reason for not doing so, with GenericApplicationContext and its subclass AnnotationConfigApplicationContext as the common implementations for custom bootstrapping. 你应该使用 ApplicationContext ，除非你有充分的理由不这样做，其中 GenericApplicationContext 及其子类 AnnotationConfigApplicationContext 是自定义引导的常见实现。 These are the primary entry points to Spring’s core container for all common purposes: loading of configuration files, triggering a classpath scan, programmatically registering bean definitions and annotated classes, and (as of 5.0) registering functional bean definitions. 这些都是 Spring 核心容器用于所有常见目的的主要入口点：加载配置文件、触发类路径扫描、以编程方式注册 bean 定义和注解类，以及（自 5.0 版本起）注册功能 bean 定义。

Because an ApplicationContext includes all the functionality of a BeanFactory, it is generally recommended over a plain BeanFactory, except for scenarios where full control over bean processing is needed. Within an ApplicationContext (such as the GenericApplicationContext implementation), several kinds of beans are detected by convention (that is, by bean name or by bean type — in particular, post-processors), while a plain DefaultListableBeanFactory is agnostic about any special beans. 因为 ApplicationContext 包含 BeanFactory 的所有功能，所以通常推荐使用 ApplicationContext 而不是普通的 BeanFactory ，除非需要完全控制 bean 处理。在 ApplicationContext （如 GenericApplicationContext 实现）中，根据惯例（即通过 bean 名称或 bean 类型——特别是后处理器）检测到多种类型的 bean，而普通的 DefaultListableBeanFactory 对任何特殊 bean 一无所知。

For many extended container features, such as annotation processing and AOP proxying, the BeanPostProcessor extension point is essential. If you use only a plain DefaultListableBeanFactory, such post-processors do not get detected and activated by default. This situation could be confusing, because nothing is actually wrong with your bean configuration. Rather, in such a scenario, the container needs to be fully bootstrapped through additional setup. 对于许多扩展容器功能，如注解处理和 AOP 代理， BeanPostProcessor 扩展点至关重要。如果你只使用纯 DefaultListableBeanFactory ，则默认情况下这些后处理器不会被检测和激活。这种情况可能会令人困惑，因为你的 bean 配置实际上并没有问题。相反，在这种情况下，容器需要通过额外的设置完全启动。

The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations. 以下表格列出了 BeanFactory 和 ApplicationContext 接口及其实现提供的功能。

Table 9. Feature Matrix 表 9. 特征矩阵

Feature 特性

BeanFactory

ApplicationContext

Bean instantiation/wiring 类实例化/连接

Yes 是的

Yes 是的

Integrated lifecycle management 集成生命周期管理

No 没有

Yes 是的

Automatic BeanPostProcessor registration 自动 BeanPostProcessor 注册

No 没有

Yes 是的

Automatic BeanFactoryPostProcessor registration 自动 BeanFactoryPostProcessor 注册

No 没有

Yes 是的

Convenient MessageSource access (for internationalization) 方便的 MessageSource 访问（用于国际化）

No 没有

Yes 是的

Built-in ApplicationEvent publication mechanism 内置 ApplicationEvent 发布机制

No 没有

Yes 是的

To explicitly register a bean post-processor with a DefaultListableBeanFactory, you need to programmatically call addBeanPostProcessor, as the following example shows:

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

To apply a BeanFactoryPostProcessor to a plain DefaultListableBeanFactory, you need to call its postProcessBeanFactory method, as the following example shows:

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

In both cases, the explicit registration steps are inconvenient, which is why the various ApplicationContext variants are preferred over a plain DefaultListableBeanFactory in Spring-backed applications, especially when relying on BeanFactoryPostProcessor and BeanPostProcessor instances for extended container functionality in a typical enterprise setup. 在两种情况下，显式注册步骤都不方便，这就是为什么在 Spring 支持的应用程序中，人们更倾向于使用各种 ApplicationContext 变体，而不是普通的 DefaultListableBeanFactory ，尤其是在依赖 BeanFactoryPostProcessor 和 BeanPostProcessor 实例以在典型的企业设置中扩展容器功能时。

An AnnotationConfigApplicationContext has all common annotation post-processors registered and may bring in additional processors underneath the covers through configuration annotations, such as @EnableTransactionManagement. At the abstraction level of Spring’s annotation-based configuration model, the notion of bean post-processors becomes a mere internal container detail. 一个 AnnotationConfigApplicationContext 注册了所有常见的注解后处理器，并且可以通过配置注解在幕后引入额外的处理器，例如 @EnableTransactionManagement 。在 Spring 基于注解的配置模型抽象层面，bean 后处理器的概念仅仅是一个内部容器细节。