2.4.2 声明一个简单的 <bean>

要在基于 XML 的 Spring 配置中声明一个 bean,我们要使用 springbeans 模式中的另外一个元素:<bean><bean> 元素类似于 JavaConfig 中的 @Bean 注解。我们可以按照如下的方式声明 CompactDiscbean:

<bean class="soundsystem.SgtPeppers" />

这里声明了一个很简单的 bean,创建这个 bean 的类通过 class 属性来指定的,并且要使用全限定的类名。

因为没有明确给定 ID,所以这个 bean 将会根据全限定类名来进行命 名。在本例中,bean 的 ID 将会是 “soundsystem.SgtPeppers#0”。其中,“#0” 是一个计数的形式,用来区分相同类型的其他 bean。如果你声明了另外一个 SgtPeppers,并且没有明确进行标识,那么它自动得到的 ID 将会是 “soundsystem.SgtPeppers#1”。

尽管自动化的 bean 命名方式非常方便,但如果你要稍后引用它的话,那自动产生的名字就没有多大的用处了。因此,通常来讲更好的办法是借助 id 属性,为每个 bean 设置一个你自己选择的名字:

<bean id="compactDisc" class="soundsystem.SgtPeppers" />

稍后将这个 bean 装配到 CDPlayer bean 之中的时候,你会用到这个具体的名字。

减少繁琐为了减少 XML 中繁琐的配置,只对那些需要按名字引用的 bean(比如,你需要将对它的引用注入到另外一个 bean中)进行明确地命名。

在进一步学习之前,让我们花点时间看一下这个简单 bean 声明的一些特征。

第一件需要注意的事情就是你不再需要直接负责创建 SgtPeppers 的实例,在基于 JavaConfig 的配置中,我们是需要这样做的。当 Spring 发现这个元素时,它将会调用 SgtPeppers 的默认构造器来创建bean。在 XML 配置中,bean 的创建显得更加被动,不过,它并没有 JavaConfig 那样强大,在 JavaConfig 配置方式中,你可以通过任何可以想象到的方法来创建 bean 实例。

另外一个需要注意到的事情就是,在这个简单的声明中,我们将 bean 的类型以字符串的形式设置在了 class 属性中。谁能保证设置给 class 属性的值是真正的类呢?Spring 的 XML 配置并不能从编译期的类型检查中受益。即便它所引用的是实际的类型,如果你重命名了类,会发生什么呢?

借助 IDE 检查 XML 的合法性使用能够感知 Spring 功能的 IDE,如 Spring Tool Suite,能够在很大程度上帮助你确保 Spring XML 配置的合法性。

以上介绍的只是 JavaConfig 要优于 XML 配置的部分原因。我建议在为你的应用选择配置风格时,要记住 XML 配置的这些缺点。接下来,我们继续 Spring XML 配置的学习进程,了解如何将 SgtPeppersbean 注入到 CDPlayer 之中。

Last updated