b spring 之使用BeanFactory 与 ApplicationContext的区别

–> go to 总目录

本节说明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接口和实现所提供的功能。

要向DefaultListableBeanFactory显式注册Bean后处理器，需要以编程方式调用addBeanPostProcessor，如以下示例所示：

要将BeanFactoryPostProcessor应用于普通的DefaultListableBeanFactory，您需要调用其postProcessBeanFactory方法，如以下示例所示

在这两种情况下，显式的注册步骤都不方便，这就是为什么在Spring支持的应用程序中，各种ApplicationContext变量比普通的DefaultListableBeanFactory更为可取的原因，尤其是在典型企业设置中依赖BeanFactoryPostProcessor和BeanPostProcessor实例来扩展容器功能时