《Spring实战(第4版)》——2.2 自动化装配bean

2.2 自动化装配bean

在本章稍后的内容中,你会看到如何借助Java和XML来进行Spring装配。尽管你会发现这些显式装配技术非常有用,但是在便利性方面,最强大的还是Spring的自动化配置。如果Spring能够进行自动化装配的话,那何苦还要显式地将这些bean装配在一起呢?

Spring从两个角度来实现自动化装配:

组件扫描(component scanning):Spring会自动发现应用上下文中所创建的bean。
自动装配(autowiring):Spring自动满足bean之间的依赖。
组件扫描和自动装配组合在一起就能发挥出强大的威力,它们能够将你的显式配置降低到最少。

为了阐述组件扫描和装配,我们需要创建几个bean,它们代表了一个音响系统中的组件。首先,要创建CompactDisc类,Spring会发现它并将其创建为一个bean。然后,会创建一个CDPlayer类,让Spring发现它,并将CompactDiscbean注入进来。

2.2.1 创建可被发现的bean
在这个MP3和流式媒体音乐的时代,CD(compact disc)显得有点典雅甚至陈旧。它不像卡带机、八轨磁带、塑胶唱片那么普遍,随着以物理载体进行音乐交付的方式越来越少,CD也变得越来越稀少了。

尽管如此,CD为我们阐述DI如何运行提供了一个很好的样例。如果你不将CD插入(注入)到CD播放器中,那么CD播放器其实是没有太大用处的。所以,可以这样说,CD播放器依赖于CD才能完成它的使命。

为了在Spring中阐述这个例子,让我们首先在Java中建立CD的概念。程序清单2.1展现了CompactDisc,它是定义CD的一个接口:

程序清单2.1 CompactDisc接口在Java中定义了CD的概念

CompactDisc的具体内容并不重要,重要的是你将其定义为一个接口。作为接口,它定义了CD播放器对一盘CD所能进行的操作。它将CD播放器的任意实现与CD本身的耦合降低到了最小的程度。

我们还需要一个CompactDisc的实现,实际上,我们可以有CompactDisc接口的多个实现。在本例中,我们首先会创建其中的一个实现,也就是程序清单2.2所示的SgtPeppers类。

程序清单2.2 带有@Component注解的CompactDisc实现类SgtPeppers

和CompactDisc接口一样,SgtPeppers的具体内容并不重要。你需要注意的就是SgtPeppers类上使用了@Component注解。这个简单的注解表明该类会作为组件类,并告知Spring要为这个类创建bean。没有必要显式配置SgtPeppersbean,因为这个类使用了@Component注解,所以Spring会为你把事情处理妥当。

不过,组件扫描默认是不启用的。我们还需要显式配置一下Spring,从而命令它去寻找带有@Component注解的类,并为其创建bean。程序清单2.3的配置类展现了完成这项任务的最简洁配置。

程序清单2.3 @ComponentScan注解启用了组件扫描

类CDPlayerConfig通过Java代码定义了Spring的装配规则。在2.3节中,我们还会更为详细地介绍基于Java的Spring配置。不过,现在我们只需观察一下CDPlayerConfig类并没有显式地声明任何bean,只不过它使用了@ComponentScan注解,这个注解能够在Spring中启用组件扫描。

如果没有其他配置的话,@ComponentScan默认会扫描与配置类相同的包。因为CDPlayerConfig类位于soundsystem包中,因此Spring将会扫描这个包以及这个包下的所有子包,查找带有@Component注解的类。这样的话,就能发现CompactDisc,并且会在Spring中自动为其创建一个bean。

如果你更倾向于使用XML来启用组件扫描的话,那么可以使用Spring context命名空间的元素。程序清单2.4展示了启用组件扫描的最简洁XML配置。

程序清单2.4 通过XML启用组件扫描

尽管我们可以通过XML的方案来启用组件扫描,但是在后面的讨论中,我更多的还是会使用基于Java的配置。如果你更喜欢XML的话,元素会有与@ComponentScan注解相对应的属性和子元素。

可能有点让人难以置信,我们只创建了两个类,就能对功能进行一番尝试了。为了测试组件扫描的功能,我们创建一个简单的JUnit测试,它会创建Spring上下文,并判断CompactDisc是不是真的创建出来了。程序清单2.5中的CDPlayerTest就是用来完成这项任务的。

程序清单2.5 测试组件扫描能够发现CompactDisc

CDPlayerTest使用了Spring的SpringJUnit4ClassRunner,以便在测试开始的时候自动创建Spring的应用上下文。注解@ContextConfiguration会告诉它需要在CDPlayerConfig中加载配置。因为CDPlayerConfig类中包含了@ComponentScan,因此最终的应用上下文中应该包含CompactDiscbean。

为了证明这一点,在测试代码中有一个CompactDisc类型的属性,并且这个属性带有@Autowired注解,以便于将CompactDiscbean注入到测试代码之中(稍后,我会讨论@Autowired)。最后,会有一个简单的测试方法断言cd属性不为null。如果它不为null的话,就意味着Spring能够发现CompactDisc类,自动在Spring上下文中将其创建为bean并将其注入到测试代码之中。

这个代码应该能够通过测试,并以测试成功的颜色显示(在你的测试运行器中,或许会希望出现绿色)。你第一个简单的组件扫描练习就成功了!尽管我们只用它创建了一个bean,但同样是这么少的配置能够用来发现和创建任意数量的bean。在soundsystem包及其子包中,所有带有@Component注解的类都会创建为bean。只添加一行@ComponentScan注解就能自动创建无数个bean,这种权衡还是很划算的。

现在,我们会更加深入地探讨@ComponentScan和@Component,看一下使用组件扫描还能做些什么。

2.2.2 为组件扫描的bean命名
Spring应用上下文中所有的bean都会给定一个ID。在前面的例子中,尽管我们没有明确地为SgtPeppersbean设置ID,但Spring会根据类名为其指定一个ID。具体来讲,这个bean所给定的ID为sgtPeppers,也就是将类名的第一个字母变为小写。

如果想为这个bean设置不同的ID,你所要做的就是将期望的ID作为值传递给@Component注解。比如说,如果想将这个bean标识为lonelyHeartsClub,那么你需要将SgtPeppers类的@Component注解配置为如下所示:

还有另外一种为bean命名的方式,这种方式不使用@Component注解,而是使用Java依赖注入规范(Java Dependency Injection)中所提供的@Named注解来为bean设置ID:

Spring支持将@Named作为@Component注解的替代方案。两者之间有一些细微的差异,但是在大多数场景中,它们是可以互相替换的。

话虽如此,我更加强烈地喜欢@Component注解,而对于@Named……怎么说呢,我感觉它的名字起得很不好。它并没有像@Component那样清楚地表明它是做什么的。因此在本书及其示例代码中,我不会再使用@Named。

2.2.3 设置组件扫描的基础包
到现在为止,我们没有为@ComponentScan设置任何属性。这意味着,按照默认规则,它会以配置类所在的包作为基础包(base package)来扫描组件。但是,如果你想扫描不同的包,那该怎么办呢?或者,如果你想扫描多个基础包,那又该怎么办呢?

有一个原因会促使我们明确地设置基础包,那就是我们想要将配置类放在单独的包中,使其与其他的应用代码区分开来。如果是这样的话,那默认的基础包就不能满足要求了。

要满足这样的需求其实也完全没有问题!为了指定不同的基础包,你所需要做的就是在@ComponentScan的value属性中指明包的名称:

如果你想更加清晰地表明你所设置的是基础包,那么你可以通过basePackages属性进行配置:

可能你已经注意到了basePackages属性使用的是复数形式。如果你揣测这是不是意味着可以设置多个基础包,那么恭喜你猜对了。如果想要这么做的话,只需要将basePackages属性设置为要扫描包的一个数组即可:

在上面的例子中,所设置的基础包是以String类型表示的。我认为这是可以的,但这种方法是类型不安全(not type-safe)的。如果你重构代码的话,那么所指定的基础包可能就会出现错误了。

除了将包设置为简单的String类型之外,@ComponentScan还提供了另外一种方法,那就是将其指定为包中所包含的类或接口:

可以看到,basePackages属性被替换成了basePackageClasses。同时,我们不是再使用String类型的名称来指定包,为basePackageClasses属性所设置的数组中包含了类。这些类所在的包将会作为组件扫描的基础包。

尽管在样例中,我为basePackageClasses设置的是组件类,但是你可以考虑在包中创建一个用来进行扫描的空标记接口(marker interface)。通过标记接口的方式,你依然能够保持对重构友好的接口引用,但是可以避免引用任何实际的应用程序代码(在稍后重构中,这些应用代码有可能会从想要扫描的包中移除掉)。

在你的应用程序中,如果所有的对象都是独立的,彼此之间没有任何依赖,就像SgtPeppersbean这样,那么你所需要的可能就是组件扫描而已。但是,很多对象会依赖其他的对象才能完成任务。这样的话,我们就需要有一种方法能够将组件扫描得到的bean和它们的依赖装配在一起。要完成这项任务,我们需要了解一下Spring自动化配置的另外一方面内容,那就是自动装配。

2.2.4 通过为bean添加注解实现自动装配
简单来说,自动装配就是让Spring自动满足bean依赖的一种方法,在满足依赖的过程中,会在Spring应用上下文中寻找匹配某个bean需求的其他bean。为了声明要进行自动装配,我们可以借助Spring的@Autowired注解。

比方说,考虑程序清单2.6中的CDPlayer类。它的构造器上添加了@Autowired注解,这表明当Spring创建CDPlayerbean的时候,会通过这个构造器来进行实例化并且会传入一个可设置给CompactDisc类型的bean。

程序清单2.6 通过自动装配,将一个CompactDisc注入到CDPlayer之中

@Autowired注解不仅能够用在构造器上,还能用在属性的Setter方法上。比如说,如果CDPlayer有一个setCompactDisc()方法,那么可以采用如下的注解形式进行自动装配:

在Spring初始化bean之后,它会尽可能得去满足bean的依赖,在本例中,依赖是通过带有@Autowired注解的方法进行声明的,也就是setCompactDisc()。

实际上,Setter方法并没有什么特殊之处。@Autowired注解可以用在类的任何方法上。假设CDPlayer类有一个insertDisc()方法,那么@Autowired能够像在setCompactDisc()上那样,发挥完全相同的作用:

不管是构造器、Setter方法还是其他的方法,Spring都会尝试满足方法参数上所声明的依赖。假如有且只有一个bean匹配依赖需求的话,那么这个bean将会被装配进来。

如果没有匹配的bean,那么在应用上下文创建的时候,Spring会抛出一个异常。为了避免异常的出现,你可以将@Autowired的required属性设置为false:

将required属性设置为false时,Spring会尝试执行自动装配,但是如果没有匹配的bean的话,Spring将会让这个bean处于未装配的状态。但是,把required属性设置为false时,你需要谨慎对待。如果在你的代码中没有进行null检查的话,这个处于未装配状态的属性有可能会出现NullPointerException。

如果有多个bean都能满足依赖关系的话,Spring将会抛出一个异常,表明没有明确指定要选择哪个bean进行自动装配。在第3章中,我们会进一步讨论自动装配中的歧义性。

@Autowired是Spring特有的注解。如果你不愿意在代码中到处使用Spring的特定注解来完成自动装配任务的话,那么你可以考虑将其替换为@Inject:

@Inject注解来源于Java依赖注入规范,该规范同时还为我们定义了@Named注解。在自动装配中,Spring同时支持@Inject和@Autowired。尽管@Inject和@Autowired之间有着一些细微的差别,但是在大多数场景下,它们都是可以互相替换的。

在@Inject和@Autowired中,我没有特别强烈的偏向性。实际上,在有的项目中,我会发现我同时使用了这两个注解。不过在本书的样例中,我会一直使用@Autowired,而你可以根据自己的情况,选择其中的任意一个。

2.2.5 验证自动装配
现在,我们已经在CDPlayer的构造器中添加了@Autowired注解,Spring将把一个可分配给CompactDisc类型的bean自动注入进来。为了验证这一点,让我们修改一下CDPlayerTest,使其能够借助CDPlayer bean播放CD:

现在,除了注入CompactDisc,我们还将CDPlayerbean注入到测试代码的player成员变量之中(它是更为通用的MediaPlayer类型)。在play()测试方法中,我们可以调用CDPlayer的play()方法,并断言它的行为与你的预期一致。

在测试代码中使用System.out.println()是稍微有点棘手的事情。因此,该样例中使用了StandardOutputStreamLog,这是来源于System Rules库的一个JUnit规则,该规则能够基于控制台的输出编写断言。在这里,我们断言SgtPeppers.play()方法的输出被发送到了控制台上。

现在,你已经了解了组件扫描和自动装配的基础知识,在第3章中,当我们介绍如何处理自动装配的歧义性时,还会继续研究组件扫描。

但是现在,我们先将组件扫描和自动装配放在一边,看一下在Spring中如何显式地装配bean,首先从通过Java代码编写配置开始。

时间: 2024-11-10 00:56:40

《Spring实战(第4版)》——2.2 自动化装配bean的相关文章

【Spring实战】—— 3 使用facotry-method创建单例Bean总结

如果有这样的需求: 1 不想再bean.xml加载的时候实例化bean,而是想把加载bean.xml与实例化对象分离. 2 实现单例的bean 以上的情况,都可以通过工厂方法factory-method来创建bean. 这样再加载bean.xml时,不会直接实例化bean,而是当调用factory-method所指的方法时,才开始真正的实例化. 首先看一下传统的单例模式的实现方式: 1 最原始的实现单例模式的方法(存在线程不安全): public class SingletonOne { pri

《Spring实战(第4版)》——导读

前言 百尺竿头更进一步.十几年前,Spring刚刚进入Java开发领域,其目标是简化企业级Java开发.它使用更为简单和轻量级的模型,该模型基于简单老式的Java对象,以此挑战了当时重量级的开发模型. 现在,已经过去了很多年,Spring也发布了众多的版本,我们可以看到Spring在企业级应用开发领域已经有了巨大的影响力.对于无数的Java项目来说,它就是事实上的标准,并且对于一些规范和它本来想取代的框架,Spring也对其演进产生了影响.毫无疑问,如果Spring不挑战之前版本的企业级Java

《Spring实战(第4版)》——2.4 通过XML装配bean

2.4 通过XML装配bean 到此为止,我们已经看到了如何让Spring自动发现和装配bean,还看到了如何进行手动干预,即通过JavaConfig显式地装配bean.但是,在装配bean的时候,还有一种可选方案,尽管这种方案可能不太合乎大家的心意,但是它在Spring中已经有很长的历史了. 在Spring刚刚出现的时候,XML是描述配置的主要方式.在Spring的名义下,我们创建了无数行XML代码.在一定程度上,Spring成为了XML配置的同义词. 尽管Spring长期以来确实与XML有着

《Spring实战(第4版)》——2.3 通过Java代码装配bean

2.3 通过Java代码装配bean 尽管在很多场景下通过组件扫描和自动装配实现Spring的自动化配置是更为推荐的方式,但有时候自动化配置的方案行不通,因此需要明确配置Spring.比如说,你想要将第三方库中的组件装配到你的应用中,在这种情况下,是没有办法在它的类上添加@Component和@Autowired注解的,因此就不能使用自动化装配的方案了. 在这种情况下,你必须要采用显式装配的方式.在进行显式配置的时候,有两种可选方案:Java和XML.在这节中,我们将会学习如何使用Java配置,

《Spring实战(第4版)》——第2章 装配Bean 2.1Spring配置的可选方案

第2章 装配Bean 本章内容: 声明bean构造器注入和Setter方法注入装配bean控制bean的创建和销毁在看电影的时候,你曾经在电影结束后留在位置上继续观看片尾字幕吗?一部电影需要由这么多人齐心协力才能制作出来,这真是有点令人难以置信!除了主要的参与人员--演员.编剧.导演和制片人,还有那些幕后人员--音乐师.特效制作人员和艺术指导,更不用说道具师.录音师.服装师.化妆师.特技演员.广告师.第一助理摄影师.第二助理摄影师.布景师.灯光师和伙食管理员(或许是最重要的人员)了. 现在想象一

《Spring实战(第4版)》——2.5 导入和混合配置

2.5 导入和混合配置 在典型的Spring应用中,我们可能会同时使用自动化和显式配置.即便你更喜欢通过JavaConfig实现显式配置,但有的时候XML却是最佳的方案. 幸好在Spring中,这些配置方案都不是互斥的.你尽可以将JavaConfig的组件扫描和自动装配和/或XML配置混合在一起.实际上,就像在2.2.1小节中所看到的,我们至少需要有一点显式配置来启用组件扫描和自动装配. 关于混合配置,第一件需要了解的事情就是在自动装配时,它并不在意要装配的bean来自哪里.自动装配的时候会考虑

《Spring实战(第4版)》——2.6 小结

2.6 小结 Spring框架的核心是Spring容器.容器负责管理应用中组件的生命周期,它会创建这些组件并保证它们的依赖能够得到满足,这样的话,组件才能完成预定的任务. 在本章中,我们看到了在Spring中装配bean的三种主要方式:自动化配置.基于Java的显式配置以及基于XML的显式配置.不管你采用什么方式,这些技术都描述了Spring应用中的组件以及这些组件之间的关系. 我同时建议尽可能使用自动化配置,以避免显式配置所带来的维护成本.但是,如果你确实需要显式配置Spring的话,应该优先

《Spring实战(第4版)》——第1章 Spring之旅 1.1简化Java开发

第1部分 Spring的核心 Spring可以做很多事情,它为企业级开发提供给了丰富的功能,但是这些功能的底层都依赖于它的两个核心特性,也就是依赖注入(dependency injection,DI)和面向切面编程(aspect-oriented programming,AOP). 作为本书的开始,在第1章"Spring之旅"中,我将快速介绍一下Spring框架,包括Spring DI和AOP的概况,以及它们是如何帮助读者解耦应用组件的. 在第2章"装配Bean"中

《Spring实战(第4版)》——1.5 小结

1.5 小结 现在,你应该对Spring的功能特性有了一个清晰的认识.Spring致力于简化企业级Java开发,促进代码的松散耦合.成功的关键在于依赖注入和AOP. 在本章,我们先体验了Spring的DI.DI是组装应用对象的一种方式,借助这种方式对象无需知道依赖来自何处或者依赖的实现方式.不同于自己获取依赖对象,对象会在运行期赋予它们所依赖的对象.依赖对象通常会通过接口了解所注入的对象,这样的话就能确保低耦合. 除了DI,我们还简单介绍了Spring对AOP的支持.AOP可以帮助应用将散落在各