Spring-装配Bean-自动化装配bean

Spring配置的可选方案

 

1.在XML中进行显式配置

2.在Java中进行显式配置

3.隐式的bean发现机制和自动装配

 

       乍看上去，提供三种可选的配置方案会使Spring变得复杂。每种配置技术所提供的功能会有一些重叠，所以在特定的场景中，确定哪种技术最为合适就会变得有些困难。

 

        Spring有多种可选方案来配置bean，这是非常棒的，但有时候你必须要在其中做出选择。

       

       这方面，并没有唯一的正确答案。你所做出的选择必须要适合你和你的项目。而且，谁说我们只能选择其中的一种方案呢？Spring的配置风格是可以互相搭配的，所以你可以选择使用XML装配一些bean，使用Spring基于Java的配置（JavaConfig）来装配另一些bean，而将剩余的bean让Spring去自动发现。即便如此，建议是尽可能地使用自动配置的机制。显式配置越少越好。

 

自动化装配bean

       

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

       ① 组件扫描（component scanning）：Spring会自动发现应用上下文中所创建的bean。

       ② 自动装配（autowiring）：Spring自动满足bean之间的依赖。

 

public interface CompactDisc{

    void play();
    
}

SgtPepers 实现CompactDisc接口

@Component
public class SgtPepers implements CompactDisc{

    private String title = "sgt,Peper's Lonly Hearts Club Band"
    private String atritst = "The Beatles";

    public void play(){
        
        System.out.println("Playing " + title + "By "+ aritst);
    }    

}

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

       不过，组件扫描默认是不启用的。我们还需要显式配置一下Spring，从而命令它去寻找带有@Component注解的类，并为其创建bean

@Configuration
@ComponentScan
public class CDPlayConfig{
}

       类CDPlayerConfig通过Java代码定义了Spring的装配规则,现在只需观察一下CDPlayerConfig类并没有显式地声明任何bean，只不过它使用了@ComponentScan注解，这个注解能够在Spring中启用组件扫描。

 

       

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

        

        

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

 

       通过XML启用组件扫描

     

         <context:component-scan base-package="soundsystem"/>

 

<context：component-scan >元素有与@ComponentScan注解相对应的属性和子元素。

 

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

 

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=CDPlayerConfig.class)
public class CDPlayerTest{

    @Autowired
    privatge CompactDisc cd;

    @Test
    public void cdShouldNotBeNull{
        assertNotNull(null);
    }

}

       为了证明这一点，在测试代码中有一个CompactDisc类型的属性,并且这个属性带有@Autowired注解，以便于将CompactDiscbean 注入到测试代码之中。最后，会有 一个简单的测试方法断言cd属性不为null。如果它不为null的话，就意

味着Spring能够发现CompactDisc类，自动在Spring上下文中将其创建为bean并将其注入到测试代码之中。

      

       尽管我们只用它创建了一个bean，但同样是这么少的配置能够用来发现和创建任意数量的bean。在soundsystem包及其子包

中，所有带有@Component注解的类都会创建为bean。只添加一 行@ComponentScan注解就能自动创建无数个bean，这种权衡还是 很划算的。

 

       为组件扫描的bean命名

     

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

 

     

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

       

@Component("loneHeartsClub")
public class SgtPeppers implements CompactDisc{
    ...
}

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

     

@Name("loneHeartsClub") 
public class SgtPeppers implements CompactDisc{
   ...
}

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

设置组件扫描的基础包

 

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

     

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

     

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

@Configuration
@ComponentScan("soundysystem")
public class CDPlayer{

}

        如果你想更加清晰地表明你所设置的是基础包，那么你可以通过 basePackages属性进行配置：可能你已经注意到了basePackages属性使用的是复数形式。如果你揣测这是不是意味着可以设置多个基础包，那么恭喜你猜对了。如 果想要这么做的话，只需要将basePackages属性设置为要扫描包的一个数组即可：

     

        

@Configuration
@ComponentScan(basePackages={"soundsystem"},{"video"})
public class CDPlayerConfig{

}

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

 

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

@Configuration
@ComponentScan(basePackageClasses={CDPlayer.class,DVDPlayer.class})
public class CDPlayerConfig{

}

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

 

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

 

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

 

通过为bean添加注解实现自动装配

        

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

 

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

通过自动装配，将一个CompactDisc注入到CDPlayer之中

 

@Component
public class CDPlayer implements MediaPlayer{

    private CompactDisc cd;

    @Autowired
    public CDPlayer(CompactDisc cd){
       this.cd = cd;
    }

    public void play(){
        cd.play();
    }
}

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

@Autowired
public void setComactDisc(CompactDisc cd){
    this.cd = cd;
}

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

 

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

@Autowired
public void insertDisc(CompactDisc cd){
     this.cd = cd;
 }

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

 

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

@Autowired(required=false)
public CDPlayer(CompactDisc cd){
    this.cd = cd;
}

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

      如果有多个bean都能满足依赖关系的话，Spring将会抛出一个异常，表明没有明确指定要选择哪个bean进行自动装配。

 

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

@Named
public class CDPlayer{
    ... 
   
    @Inject
    public CDPlayer(CompactDisc cd){
      this.cd = cd;
    }
   ...
}

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

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

 

验证自动装配

    

     

        已经在CDPlayer的构造器中添加了@Autowired注解，Spring将把一个可分配给CompactDisc类型的bean自动注入进来。为

了验证这一点，让我们修改一下CDPlayerTest，使其能够借助CDPlayer bean播放CD：

        

@RunWith(SpringJunit4ClassRunner.class)
@ContextConfiguration(classes=CDPlayer.class)
public class CDPlayer{

    @Rule
    public final StandardOutputStreamLog log = new StandardOutpubStream();

    @Autowired
    private MediaPlayer player;

    @Test
    public void cdShouldNotBeNull(){
        assertNotNull(cd);
    }

    @Test
    public void play(){
        play.play();
        assertEquals("Playing Sgt.Pepper's Lone Hearts Club Band" + " by The Beatles\n",
        log.getLog());
    }

}

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

       

       在测试代码中使用System.out.println()是稍微有点棘手的事情。因此，该样例中使用了StandardOutputStreamLog，这是来

源于System Rules库（http://stefanbirkner.github.io/system- rules/index.html）的一个JUnit规则，该规则能够基于控制台的输出编写断言。在这里，我们断言SgtPeppers.play()方法的输出被发送到了控制台上。