此版本仍在开发中,尚未被视为稳定版本。最新的稳定版本请使用 Spring Framework 6.1.13! |
此版本仍在开发中,尚未被视为稳定版本。最新的稳定版本请使用 Spring Framework 6.1.13! |
API 为 Spring 的 IoC 功能提供了基础。
它的特定 Contract 主要用于与 Spring 和
相关的第三方框架及其实现
是更高级别容器中的关键委托。BeanFactory
DefaultListableBeanFactory
GenericApplicationContext
BeanFactory
和相关接口(如 、 、 )是其他框架组件的重要集成点。
通过不需要任何注释甚至反射,它们允许非常高效
容器与其组件之间的交互。应用程序级 bean 可以
使用相同的回调接口,但通常更喜欢声明性依赖项
注入,而是通过 Comments 或编程配置。BeanFactoryAware
InitializingBean
DisposableBean
请注意,核心 API 级别及其实现不会对配置格式或任何
要使用的组件注释。所有这些风格都来自扩展
(例如 和 )和
对共享库进行操作,将其作为核心元数据表示形式。
这就是 Spring 的容器如此灵活和可扩展的本质。BeanFactory
DefaultListableBeanFactory
XmlBeanDefinitionReader
AutowiredAnnotationBeanPostProcessor
BeanDefinition
BeanFactory
或?ApplicationContext
本节介绍 和 容器级别之间的差异以及对引导程序的影响。BeanFactory
ApplicationContext
除非你有充分的理由不这样做,否则你应该使用 an 及其子类作为自定义引导的常见实现。这些是主要条目
指向 Spring 的核心容器,用于所有常见目的:加载配置
文件, 触发类路径扫描, 以编程方式注册 Bean 定义
和带 Comments 的类,以及(从 5.0 开始)注册函数式 bean 定义。ApplicationContext
GenericApplicationContext
AnnotationConfigApplicationContext
因为 an 包括 的所有功能 ,所以它是
一般推荐 平原 ,但 full
需要控制 Bean 处理。在 an(例如实现)中,检测到多种 bean
按约定(即按 Bean 名称或 Bean 类型 — 特别是后处理器),
而 Plain 对任何特殊的豆子都是不可知的。ApplicationContext
BeanFactory
BeanFactory
ApplicationContext
GenericApplicationContext
DefaultListableBeanFactory
对于许多扩展容器功能,例如注释处理和 AOP 代理,
BeanPostProcessor
扩展点是必不可少的。
如果仅使用 plain ,则此类后处理器不会
默认情况下被检测并激活。这种情况可能会令人困惑,因为
您的 bean 配置实际上没有任何问题。相反,在这种情况下,
容器需要通过其他设置完全引导。DefaultListableBeanFactory
下表列出了 和 interfaces 和实现提供的功能。BeanFactory
ApplicationContext
特征 | BeanFactory |
ApplicationContext |
---|---|---|
Bean 实例化/连接 |
是的 |
是的 |
集成的生命周期管理 |
不 |
是的 |
自动注册 |
不 |
是的 |
自动注册 |
不 |
是的 |
便捷访问(用于国际化) |
不 |
是的 |
内置发布机制 |
不 |
是的 |
要使用 ,
您需要以编程方式调用 ,如下例所示:DefaultListableBeanFactory
addBeanPostProcessor
-
Java
-
Kotlin
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
要将 a 应用于普通 ,
您需要调用其方法,如下例所示:BeanFactoryPostProcessor
DefaultListableBeanFactory
postProcessBeanFactory
-
Java
-
Kotlin
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)
在这两种情况下,显式注册步骤都很不方便,即
为什么在 Spring 支持的应用程序中,各种变体比 plain 更受欢迎,尤其是当
依赖 和 实例进行扩展
典型企业设置中的容器功能。ApplicationContext
DefaultListableBeanFactory
BeanFactoryPostProcessor
BeanPostProcessor
An 具有所有常见的 Annotation 后处理器
已注册,并可能在
覆盖配置注释,例如 .
在 Spring 基于 Comments 的配置模型的抽象层,
Bean 后处理器的概念变成了一个纯粹的内部容器细节。 |
特征 | BeanFactory |
ApplicationContext |
---|---|---|
Bean 实例化/连接 |
是的 |
是的 |
集成的生命周期管理 |
不 |
是的 |
自动注册 |
不 |
是的 |
自动注册 |
不 |
是的 |
便捷访问(用于国际化) |
不 |
是的 |
内置发布机制 |
不 |
是的 |
An 具有所有常见的 Annotation 后处理器
已注册,并可能在
覆盖配置注释,例如 .
在 Spring 基于 Comments 的配置模型的抽象层,
Bean 后处理器的概念变成了一个纯粹的内部容器细节。 |