1.16. The BeanFactory

1.16. The BeanFactory

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. Application-level beans may use the same callback interfaces but typically prefer declarative dependency injection instead, either through annotations or through programmatic configuration.

BeanFactory和相关接口(如BeanFactoryAware、InitializingBean、DisposableBean)
是其他框架组件的重要整合点。
由于不需要任何注释甚至反射，它们允许容器与其组件之间非常有效的交互。
应用程序级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的容器如此灵活和可扩展的本质所在。

1.16.1. BeanFactory or ApplicationContext?

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. 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.

除非有很好的理由，否则应该使用ApplicationContext，
使用GenericApplicationContext及其
子类AnnotationConfigApplicationContext作为自定义引导的通用实现。
这些是用于所有常见目的的Spring核心容器的主要入口点:
加载配置文件、触发类路径扫描、以编程方式注册bean definition和带注释的
类，以及(从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的所有功能，
所以一般建议它优于普通的BeanFactory，除非需要对bean
处理进行完全控制的场景除外。
在ApplicationContext(比如GenericApplicationContext实现)的
几种检测到bean按照惯例
(也就是说,由bean名称或bean类型——特别是, post-processors),
而普通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，
默认情况下不会检测到这种post-processors并激活它。
这种情况可能令人困惑，因为您的bean配置实际上没有任何错误。
相反，在这样的场景中，容器需要通过附加的设置进行完全引导。

The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations.

下表列出了BeanFactory和ApplicationContext接口和实现提供的特性。

Table 9. Feature Matrix

Feature	BeanFactory	ApplicationContext
Bean instantiation/wiring	Yes	Yes
Integrated lifecycle management	No	Yes
Automatic BeanPostProcessor registration	No	Yes
Automatic BeanFactoryPostProcessor registration	No	Yes
Convenient MessageSource access (for internalization)	No	Yes
Built-in ApplicationEvent publication mechanism	No	Yes

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

要显式地用DefaultListableBeanFactory注册一个bean post-processor，你需要通过编程调用addBeanPostProcessor，如下面的例子所示:

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

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

要将一个BeanFactoryPostProcessor应用到一个普通的DefaultListableBeanFactory，
你需要调用它的postProcessBeanFactory方法，如下面的例子所示:

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);

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.

在这两种情况下,明确登记步骤是不方便的,这就是为什么各种
ApplicationContext变体在基于Spring的应用程序都优于
纯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注册了所有公共注释post-processors，
并可能通过配置注释
(如@EnableTransactionManagement)在后台引入额外的处理器。
在Spring的基于注解的配置模型的抽象层上，bean post-processors的概念
仅仅成为内部容器的细节。