自动装配协作者
Infra 容器可以自动装配协作 bean 之间的关系。
您可以通过检查 ApplicationContext 的内容,让 Infra 自动为您的 bean 解析协作者(其他 bean)。
自动装配具有以下优点:
-
自动装配可以显着减少指定属性或构造函数参数的需要。(其他机制,如 本章其他地方讨论的 bean 模板在这方面也很有价值。)
-
自动装配可以随着对象的发展更新配置。例如,如果您需要向类添加依赖项,则可以自动满足该依赖项,而无需修改配置。 因此,自动装配在开发过程中特别有用,而且不会否定在代码库变得更稳定时切换到显式装配的选项。
当使用基于 XML 的配置元数据(请参阅 依赖注入)时,
您可以使用 <bean/> 元素的 autowire 属性为 bean 定义指定自动装配模式。
自动装配功能有四种模式。您指定每个 bean 的自动装配,从而可以选择要自动装配的 bean。
下表描述了四种自动装配模式:
| 模式 | 说明 |
|---|---|
|
(默认) 不自动装配。Bean 引用必须由 |
|
按属性名称自动装配。Infra 查找与需要自动装配的属性同名的 bean。
例如,如果 bean 定义设置为按名称自动装配,并且它包含一个 |
|
如果容器中恰好存在一个属性类型的 bean,则允许自动装配属性。
如果存在多个,则会抛出致命异常,这表明您可能无法对该 bean 使用 |
|
类似于 |
使用 byType 或 constructor 自动装配模式,您可以装配数组和类型化集合。
在这种情况下,容器内所有匹配预期类型的自动装配候选者都将被提供以满足依赖项。
如果预期的键类型为 String,您可以自动装配强类型 Map 实例。
自动装配的 Map 实例的值由所有匹配预期类型的 bean 实例组成,Map 实例的键包含相应的 bean 名称。
自动装配的局限性和缺点
当在整个项目中一致地使用自动装配时,它的效果最好。 如果通常不使用自动装配,开发人员可能会对仅用于装配一个或两个 bean 定义感到困惑。
考虑自动装配的局限性和缺点:
-
property和constructor-arg设置中的显式依赖项始终覆盖自动装配。 您不能自动装配简单属性,例如原语、Strings和Classes(以及此类简单属性的数组)。 此限制是设计使然。 -
自动装配不如显式装配精确。尽管如前面的表中所述,Infra 在遇到可能产生意外结果的歧义时会小心避免猜测。 您的 Infra 管理对象之间的关系不再被显式记录。
-
能够从 Infra 容器生成文档的工具可能无法获得装配信息。
-
容器内的多个 bean 定义可能与要自动装配的 setter 方法或构造函数参数指定的类型匹配。 对于数组、集合或
Map实例,这不一定是个问题。 但是,对于期望单个值的依赖项,这种歧义不会被任意解决。如果没有唯一的 bean 定义可用,则会抛出异常。
在后一种情况下,您有几个选择:
从自动装配中排除 Bean
在每个 bean 的基础上,您可以从自动装配中排除一个 bean。
在 Infra XML 格式中,将 <bean/> 元素的 autowire-candidate 属性设置为 false。
容器使该特定 bean 定义对自动装配基础设施不可用(包括注解样式配置,例如 @Autowired)。
autowire-candidate 属性旨在仅影响基于类型的自动装配。
它不影响按名称的显式引用,即使指定的 bean 未标记为自动装配候选者,也会解析该引用。
因此,如果名称匹配,按名称自动装配仍然会注入 bean。
|
您还可以根据针对 bean 名称的模式匹配来限制自动装配候选者。
顶级 <beans/> 元素在其 default-autowire-candidates 属性中接受一个或多个模式。
例如,要将自动装配候选者状态限制为名称以 Repository 结尾的任何 bean,请提供值 *Repository。
要提供多个模式,请在逗号分隔的列表中定义它们。
bean 定义的 autowire-candidate 属性的显式值 true 或 false 始终优先。
对于此类 bean,模式匹配规则不适用。
这些技术对于您永远不想通过自动装配注入到其他 bean 中的 bean 很有用。 这并不意味着被排除的 bean 本身不能使用自动装配进行配置。 相反,bean 本身不是自动装配其他 bean 的候选者。