b spring 之使用BeanFactory 与 ApplicationContext的区别

文章目录


本节说明BeanFactory和ApplicationContext容器级别之间的区别以及对引导的影响。
ApplicationContext实现了BeanFactory的接口
应使用ApplicationContext
除非有充分的理由,否则应使用ApplicationContext,将GenericApplicationContext及其子类AnnotationConfigApplicationContext作为自定义引导的常见实现。这些是用于所有常见目的的Spring核心容器的主要入口点:加载配置文件,触发类路径扫描,以编程方式注册Bean定义和带注释的类,以及(从5.0版本开始)注册功能性Bean定义。
原因
因为ApplicationContext包含BeanFactory的所有功能,所以通常建议在纯BeanFactory上使用,除非需要对Bean处理的完全控制。在ApplicationContext(例如GenericApplicationContext实现)中,按照约定(即,按bean名称或按bean类型(尤其是后处理器))检测到几种bean,而普通的DefaultListableBeanFactory则与任何特殊bean无关。

对于许多扩展的容器功能,例如注释处理和AOP代理, BeanPostProcessor扩展点至关重要。如果仅使用普通的DefaultListableBeanFactory,则默认情况下不会检测到此类后处理器并将其**。这种情况可能会造成混乱,因为您的bean配置实际上没有任何问题。而是在这种情况下,需要通过其他设置完全引导容器。

功能对比

下表列出了BeanFactory和ApplicationContext接口和实现所提供的功能。
b spring 之使用BeanFactory 与 ApplicationContext的区别

要向DefaultListableBeanFactory显式注册Bean后处理器,需要以编程方式调用addBeanPostProcessor,如以下示例所示:
b spring 之使用BeanFactory 与 ApplicationContext的区别
要将BeanFactoryPostProcessor应用于普通的DefaultListableBeanFactory,您需要调用其postProcessBeanFactory方法,如以下示例所示
b spring 之使用BeanFactory 与 ApplicationContext的区别
在这两种情况下,显式的注册步骤都不方便,这就是为什么在Spring支持的应用程序中,各种ApplicationContext变量比普通的DefaultListableBeanFactory更为可取的原因,尤其是在典型企业设置中依赖BeanFactoryPostProcessor和BeanPostProcessor实例来扩展容器功能时