详解 Spring 3.0 基于 Annotation 的依赖注入实现

简介：Spring的依赖配置方式与Spring框架的内核自身是松耦合设计的。然而，直到Spring3.0以前，使用XML进行依赖配置几乎是唯一的选择。Spring3.0的出现改变了这一状况，它提供了一系列的针对依赖注入的注解，这使得SpringIoC在XML文件之外多了一种可行的选择。本文将详细介绍如何使用这些注解进行依赖配置的管理。

使用@Repository、@Service、@Controller和@Component将类标识为Bean

Spring自2.0版本开始，陆续引入了一些注解用于简化Spring的开发。@Repository注解便属于最先引入的一批，它用于将数据访问层(DAO层)的类标识为SpringBean。具体只需将该注解标注在DAO类上即可。同时，为了让Spring能够扫描类路径中的类并识别出@Repository注解，需要在XML配置文件中启用Bean的自动扫描功能，这可以通过<context:component-scan/>实现。如下所示：

// 首先使用 @Repository 将 DAO 类声明为 Bean 
 package bookstore.dao; 
 @Repository 
 public class UserDaoImpl implements UserDao{ …… }

其次，在XML配置文件中启动Spring的自动扫描功能

<beans … > 
    ……
 <context:component-scan base-package=”bookstore.dao” /> 
……
 </beans>

如此，我们就不再需要在XML中显式使用<bean/>进行Bean的配置。Spring在容器初始化时将自动扫描base-package指定的包及其子包下的所有class文件，所有标注了@Repository的类都将被注册为SpringBean。

为什么@Repository只能标注在DAO类上呢？这是因为该注解的作用不只是将类识别为Bean，同时它还能将所标注的类中抛出的数据访问异常封装为Spring的数据访问异常类型。Spring本身提供了一个丰富的并且是与具体的数据访问技术无关的数据访问异常结构，用于封装不同的持久层框架抛出的异常，使得异常独立于底层的框架。

Spring2.5在@Repository的基础上增加了功能类似的额外三个注解：@Component、@Service、@Constroller，它们分别用于软件系统的不同层次：

@Component是一个泛化的概念，仅仅表示一个组件(Bean)，可以作用在任何层次。

@Service通常作用在业务层，但是目前该功能与@Component相同。

@Constroller通常作用在控制层，但是目前该功能与@Component相同。

通过在类上使用@Repository、@Component、@Service和@Constroller注解，Spring会自动创建相应的BeanDefinition对象，并注册到ApplicationContext中。这些类就成了Spring受管组件。这三个注解除了作用于不同软件层次的类，其使用方式与@Repository是完全相同的。

另外，除了上面的四个注解外，用户可以创建自定义的注解，然后在注解上标注@Component，那么，该自定义注解便具有了与所@Component相同的功能。不过这个功能并不常用。

当一个Bean被自动检测到时，会根据那个扫描器的BeanNameGenerator策略生成它的bean名称。默认情况下，对于包含name属性的@Component、@Repository、@Service和@Controller，会把name取值作为Bean的名字。如果这个注解不包含name值或是其他被自定义过滤器发现的组件，默认Bean名称会是小写开头的非限定类名。如果你不想使用默认bean命名策略，可以提供一个自定义的命名策略。首先实现BeanNameGenerator接口，确认包含了一个默认的无参数构造方法。然后在配置扫描器时提供一个全限定类名，如下所示：

<beans ...> 
 <context:component-scan 
    base-package="a.b" name-generator="a.SimpleNameGenerator"/> 
 </beans>

与通过XML配置的SpringBean一样，通过上述注解标识的Bean，其默认作用域是"singleton"，为了配合这四个注解，在标注Bean的同时能够指定Bean的作用域，Spring2.5引入了@Scope注解。使用该注解时只需提供作用域的名称就行了，如下所示：

@Scope("prototype") 
 @Repository 
 public class Demo { … }

如果你想提供一个自定义的作用域解析策略而不使用基于注解的方法，只需实现ScopeMetadataResolver接口，确认包含一个默认的没有参数的构造方法。然后在配置扫描器时提供全限定类名：

<context:component-scan base-package="a.b"
 scope-resolver="footmark.SimpleScopeResolver" />

使用@PostConstruct和@PreDestroy指定生命周期回调方法

SpringBean是受SpringIoC容器管理，由容器进行初始化和销毁的（prototype类型由容器初始化之后便不受容器管理），通常我们不需要关注容器对Bean的初始化和销毁操作，由Spring经过构造函数或者工厂方法创建的Bean就是已经初始化完成并立即可用的。然而在某些情况下，可能需要我们手工做一些额外的初始化或者销毁操作，这通常是针对一些资源的获取和释放操作。Spring1.x为此提供了两种方式供用户指定执行生命周期回调的方法。

第一种方式是实现Spring提供的两个接口：InitializingBean和DisposableBean。如果希望在Bean初始化完成之后执行一些自定义操作，则可以让Bean实现InitializingBean接口，该接口包含一个afterPropertiesSet()方法，容器在为该Bean设置了属性之后，将自动调用该方法；如果Bean实现了DisposableBean接口，则容器在销毁该Bean之前，将调用该接口的destroy()方法。这种方式的缺点是，让Bean类实现Spring提供的接口，增加了代码与Spring框架的耦合度，因此不推荐使用。

第二种方式是在XML文件中使用<bean>的init-method和destroy-method属性指定初始化之后和销毁之前的回调方法，代码无需实现任何接口。这两个属性的取值是相应Bean类中的初始化和销毁方法，方法名任意，但是方法不能有参数。示例如下：

<bean id=”userService” 
 class=”bookstore.service.UserService” 
 init-method=”init” destroy-method=”destroy”> 
    …
 </bean>

Spring2.5在保留以上两种方式的基础上，提供了对JSR-250的支持。JSR-250规范定义了两个用于指定声明周期方法的注解：@PostConstruct和@PreDestroy。这两个注解使用非常简单，只需分别将他们标注于初始化之后执行的回调方法或者销毁之前执行的回调方法上。由于使用了注解，因此需要配置相应的Bean后处理器，亦即在XML中增加如下一行：

<context:annotation-config />

比较上述三种指定生命周期回调方法的方式，第一种是不建议使用的，不但其用法不如后两种方式灵活，而且无形中增加了代码与框架的耦合度。后面两种方式开发者可以根据使用习惯选择其中一种，但是最好不要混合使用，以免增加维护的难度。

使用@Required进行Bean的依赖检查

依赖检查的作用是，判断给定Bean的相应Setter方法是否都在实例化的时候被调用了。而不是判断字段是否已经存在值了。Spring进行依赖检查时，只会判断属性是否使用了Setter注入。如果某个属性没有使用Setter注入，即使是通过构造函数已经为该属性注入了值，Spring仍然认为它没有执行注入，从而抛出异常。另外，Spring只管是否通过Setter执行了注入，而对注入的值却没有任何要求，即使注入的<null/>，Spring也认为是执行了依赖注入。

<bean>标签提供了dependency-check属性用于进行依赖检查。该属性的取值包括以下几种：

旧版本使用dependency-check在配置文件中设置，缺点是粒度较粗。使用Spring2.0提供的@Required注解，提供了更细粒度的控制。@Required注解只能标注在Setter方法之上。因为依赖注入的本质是检查Setter方法是否被调用了，而不是真的去检查属性是否赋值了以及赋了什么样的值。如果将该注解标注在非setXxxx()类型的方法则被忽略。

为了让Spring能够处理该注解，需要激活相应的Bean后处理器。要激活该后处理器，只需在XML中增加如下一行即可。

<context:annotation-config/>

当某个被标注了@Required的Setter方法没有被调用，则Spring在解析的时候会抛出异常，以提醒开发者对相应属性进行设置。

使用@Resource、@Autowired和@Qualifier指定Bean的自动装配策略

自动装配是指，Spring在装配Bean的时候，根据指定的自动装配规则，将某个Bean所需要引用类型的Bean注入进来。<bean>元素提供了一个指定自动装配类型的autowire属性，该属性有如下选项：

当使用byType或者constructor类型的自动装配的时候，自动装配也支持引用类型的数组或者使用了泛型的集合，这样，Spring就会检查容器中所有类型匹配的Bean，组成集合或者数组后执行注入。对于使用了泛型的Map类型，如果键是String类型，则Spring也会自动执行装配，将所有类型匹配的Bean作为值，Bean的名字作为键。

我们可以给<beans>增加default-autowire属性，设置默认的自动封装策略。默认值为"no"。如果使用自动装配的同时，也指定了property或者constructor-arg标签，则显式指定的值将覆盖自动装配的值。目前的自动封装不支持简单类型，比如基本类型、String、Class，以及它们的数组类型。

在按类型匹配的时候(可能是byType、constructor、autodetect)，同一个类型可能存在多个Bean，如果被注入的属性是数组、集合或者Map，这可能没有问题，但是如果只是简单的引用类型，则会抛出异常。解决方法有如下几种：

取消该Bean的自动装配特性，使用显式的注入。我们可能不希望某个Bean被当作其他Bean执行自动封装时的候选对象，我们可以给该<bean>增加autowire-candidate="false"。(autowire-candidate属性和autowire属性相互独立，互不相干。某个Bean可以将autowire-candidate设置为false，同时使用autowire特性。)另外，我们可以设置<beans>的default-autowire-candidates属性，可以在该属性中指定可以用于自动装配候选Bean的匹配模式，比如default-autowire-candidates="*serv,*dao"，这表示所有名字以serv或者dao结尾的Bean被列为候选，其他则忽略，相当于其他Bean都指定为autowire-candidate="false"，此时可以显式为<bean>指定autowire-candidate="true"。在<bean>上指定的设置要覆盖<beans>上指定的设置。

如果在多个类型相同的Bean中有首选的Bean，那么可以将该<bean>的primary属性设置为"true"，这样自动装配时便优先使用该Bean进行装配。此时不能将autowire-candidate设为false。

如果使用的是Java5以上版本，可以使用注解进行更细粒度的控制。

使用@Autowired和@Qualifier注解执行自动装配

使用@Autowired注解进行装配，只能是根据类型进行匹配。@Autowired注解可以用于Setter方法、构造函数、字段，甚至普通方法，前提是方法必须有至少一个参数。@Autowired可以用于数组和使用泛型的集合类型。然后Spring会将容器中所有类型符合的Bean注入进来。@Autowired标注作用于Map类型时，如果Map的key为String类型，则Spring会将容器中所有类型符合Map的value对应的类型的Bean增加进来，用Bean的id或name作为Map的key。

@Autowired标注作用于普通方法时，会产生一个副作用，就是在容器初始化该Bean实例的时候就会调用该方法。当然，前提是执行了自动装配，对于不满足装配条件的情况，该方法也不会被执行。

当标注了@Autowired后，自动注入不能满足，则会抛出异常。我们可以给@Autowired标注增加一个required=false属性，以改变这个行为。另外，每一个类中只能有一个构造函数的@Autowired.required()属性为true。否则就出问题了。如果用@Autowired同时标注了多个构造函数，那么，Spring将采用贪心算法匹配构造函数(构造函数最长)。

@Autowired还有一个作用就是，如果将其标注在BeanFactory类型、ApplicationContext类型、ResourceLoader类型、ApplicationEventPublisher类型、MessageSource类型上，那么Spring会自动注入这些实现类的实例，不需要额外的操作。

当容器中存在多个Bean的类型与需要注入的相同时，注入将不能执行，我们可以给@Autowired增加一个候选值，做法是在@Autowired后面增加一个@Qualifier标注，提供一个String类型的值作为候选的Bean的名字。举例如下：

@Autowired(required=false) 
 @Qualifier("ppp") 
 public void setPerson(person p){}

@Qualifier甚至可以作用于方法的参数(对于方法只有一个参数的情况，我们可以将@Qualifer标注放置在方法声明上面，但是推荐放置在参数前面)，举例如下：

@Autowired(required=false) 
 public void sayHello(@Qualifier("ppp")Person p,String name){}

我们可以在配置文件中指定某个Bean的qualifier名字，方法如下：

<bean id="person" class="footmark.spring.Person"> 
    <qualifier value="ppp"/> 
 </bean>

如果没有明确指定Bean的qualifier名字，那么默认名字就是Bean的名字。通常，qualifier应该是有业务含义的，例如"domain"，"persistent"等，而不应该是类似"person"方式。

我们还可以将@Qualifier标注在集合类型上，那么所有qualifier名字与指定值相同的Bean都将被注入进来。

最后，配置文件中需要指定每一个自定义注解的属性值。我们可以使用<meta>标签来代替<qualifier/>标签，如果<meta>标签和<qualifier/>标签同时出现，那么优先使用<qualifier>标签。如果没有<qualifier>标签，那么会用<meta>提供的键值对来封装<qualifier>标签。示例如下：

<bean class="footmark.HelloWorld"> 
 <qualifier type="MovieQualifier"> 
 <attribute key="format" value="VHS"/> 
 <attribute key="genre" value="Comedy"/> 
 </qualifier> 
 </bean> 
 <bean class="footmark.HelloWorld"> 
 <meta key="format" value="DVD"/> 
 <meta key="genre" value="Action"/> 
 </bean>

@Autowired注解对应的后处理注册与前面相似，只需在配置文件中增加如下一行即可：

<context:annotation-config/>

如果@Autowired注入的是BeanFactory、ApplicationContext、ResourceLoader等系统类型，那么则不需要@Qualifier，此时即使提供了@Qualifier注解，也将会被忽略；而对于自定义类型的自动装配，如果使用了@Qualifier注解并且没有名字与之匹配的Bean，则自动装配匹配失败。

使用JSR-250中的@Resource和@Qualifier注解

如果希望根据name执行自动装配，那么应该使用JSR-250提供的@Resource注解，而不应该使用@Autowired与@Qualifier的组合。

@Resource使用byName的方式执行自动封装。@Resource标注可以作用于带一个参数的Setter方法、字段，以及带一个参数的普通方法上。@Resource注解有一个name属性，用于指定Bean在配置文件中对应的名字。如果没有指定name属性，那么默认值就是字段或者属性的名字。@Resource和@Qualifier的配合虽然仍然成立，但是@Qualifier对于@Resource而言，几乎与name属性等效。

如果@Resource没有指定name属性，那么使用byName匹配失败后，会退而使用byType继续匹配，如果再失败，则抛出异常。在没有为@Resource注解显式指定name属性的前提下，如果将其标注在BeanFactory类型、ApplicationContext类型、ResourceLoader类型、ApplicationEventPublisher类型、MessageSource类型上，那么Spring会自动注入这些实现类的实例，不需要额外的操作。此时name属性不需要指定(或者指定为"")，否则注入失败；如果使用了@Qualifier，则该注解将被忽略。而对于用户自定义类型的注入，@Qualifier和name等价，并且不被忽略。

<bean>的primary和autowire-candidate属性对@Resource、@Autowired仍然有效。

使用@Configuration和@Bean进行Bean的声明

虽然2.0版本发布以来，Spring陆续提供了十多个注解，但是提供的这些注解只是为了在某些情况下简化XML的配置，并非要取代XML配置方式。这一点可以从SpringIoC容器的初始化类可以看出：ApplicationContext接口的最常用的实现类是ClassPathXmlApplicationContext和FileSystemXmlApplicationContext，以及面向Portlet的XmlPortletApplicationContext和面向web的XmlWebApplicationContext，它们都是面向XML的。Spring3.0新增了另外两个实现类：AnnotationConfigApplicationContext和AnnotationConfigWebApplicationContext。从名字便可以看出，它们是为注解而生，直接依赖于注解作为容器配置信息来源的IoC容器初始化类。由于AnnotationConfigWebApplicationContext是AnnotationConfigApplicationContext的web版本，其用法与后者相比几乎没有什么差别，因此本文将以AnnotationConfigApplicationContext为例进行讲解。

AnnotationConfigApplicationContext搭配上@Configuration和@Bean注解，自此，XML配置方式不再是SpringIoC容器的唯一配置方式。两者在一定范围内存在着竞争的关系，但是它们在大多数情况下还是相互协作的关系，两者的结合使得SpringIoC容器的配置更简单，更强大。

之前，我们将配置信息集中写在XML中，如今使用注解，配置信息的载体由XML文件转移到了Java类中。我们通常将用于存放配置信息的类的类名以“Config”结尾，比如AppDaoConfig.java、AppServiceConfig.java等等。我们需要在用于指定配置信息的类上加上@Configuration注解，以明确指出该类是Bean配置的信息源。并且Spring对标注Configuration的类有如下要求：

配置类不能是final的；

配置类不能是本地化的，亦即不能将配置类定义在其他类的方法内部；

配置类必须有一个无参构造函数。

AnnotationConfigApplicationContext将配置类中标注了@Bean的方法的返回值识别为SpringBean，并注册到容器中，受IoC容器管理。@Bean的作用等价于XML配置中的<bean/>标签。示例如下：

@Configuration 
 public class BookStoreDaoConfig{ 
    @Bean 
    public UserDao userDao(){ return new UserDaoImpl();} 
    @Bean 
    public BookDao bookDao(){return new BookDaoImpl();} 
 }

Spring在解析到以上文件时，将识别出标注@Bean的所有方法，执行之，并将方法的返回值(这里是UserDaoImpl和BookDaoImpl对象)注册到IoC容器中。默认情况下，Bean的名字即为方法名。因此，与以上配置等价的XML配置如下：

<bean id=”userDao” class=”bookstore.dao.UserDaoImpl”/> 
 <bean id=”bookDao” class=”bookstore.dao.BookDaoImpl”/>

@Bean具有以下四个属性：

name--指定一个或者多个Bean的名字。这等价于XML配置中<bean>的name属性。

initMethod--容器在初始化完Bean之后，会调用该属性指定的方法。这等价于XML配置中<bean>的init-method属性。

destroyMethod--该属性与initMethod功能相似，在容器销毁Bean之前，会调用该属性指定的方法。这等价于XML配置中<bean>的destroy-method属性。

autowire--指定Bean属性的自动装配策略，取值是Autowire类型的三个静态属性。Autowire.BY_NAME，Autowire.BY_TYPE，Autowire.NO。与XML配置中的autowire属性的取值相比，这里少了constructor，这是因为constructor在这里已经没有意义了。

@Bean没有直接提供指定作用域的属性，可以通过@Scope来实现该功能，关于@Scope的用法已在上文列举。

下面讲解基于注解的容器初始化。AnnotationConfigApplicationContext提供了三个构造函数用于初始化容器。

AnnotationConfigApplicationContext()：该构造函数初始化一个空容器，容器不包含任何Bean信息，需要在稍后通过调用其register()方法注册配置类，并调用refresh()方法刷新容器。

AnnotationConfigApplicationContext(Class<?>...annotatedClasses)：这是最常用的构造函数，通过将涉及到的配置类传递给该构造函数，以实现将相应配置类中的Bean自动注册到容器中。

AnnotationConfigApplicationContext(String...basePackages)：该构造函数会自动扫描以给定的包及其子包下的所有类，并自动识别所有的SpringBean，将其注册到容器中。它不但识别标注@Configuration的配置类并正确解析，而且同样能识别使用@Repository、@Service、@Controller、@Component标注的类。

除了使用上面第三种类型的构造函数让容器自动扫描Bean的配置信息以外，AnnotationConfigApplicationContext还提供了scan()方法，其功能与上面也类似，该方法主要用在容器初始化之后动态增加Bean至容器中。调用了该方法以后，通常需要立即手动调用refresh()刷新容器，以让变更立即生效。

需要注意的是，AnnotationConfigApplicationContext在解析配置类时，会将配置类自身注册为一个Bean，因为@Configuration注解本身定义时被@Component标注了。因此可以说，一个@Configuration同时也是一个@Component。大多数情况下，开发者用不到该Bean，并且在理想情况下，该Bean应该是对开发者透明的。@Configuration的定义如下所示：

@Target({ElementType.TYPE}) 
 @Retention(RetentionPolicy.RUNTIME) 
 @Documented 
 @Component 
 public @interface Configuration { 
 String value() default ""; 
 }

在一般的项目中，为了结构清晰，通常会根据软件的模块或者结构定义多个XML配置文件，然后再定义一个入口的配置文件，该文件使用<import/>将其他的配置文件组织起来。最后只需将该文件传给ClassPathXmlApplicationContext的构造函数即可。针对基于注解的配置，Spring也提供了类似的功能，只需定义一个入口配置类，并在该类上使用@Import注解引入其他的配置类即可，最后只需要将该入口类传递给AnnotationConfigApplicationContext。具体示例如下：

@Configuration 
 @Import({BookStoreServiceConfig.class,BookStoreDaoConfig.class}) 
 public class BookStoreConfig{ … }

混合使用XML与注解进行Bean的配置

设计@Configuration和@Bean的初衷，并不是为了完全取代XML，而是为了在XML之外多一种可行的选择。由于Spring自发布以来，Spring开发小组便不断简化XML配置，使得XML配置方式已经非常成熟，加上Spring2.0以后出现了一系列命名空间的支持，使得XML配置方式成为了使用简单、功能强大的Bean定义方式。而且，XML配置的一些高级功能目前还没有相关注解能够直接支持。因此，在目前的多数项目中，要么使用纯粹的XML配置方式进行Bean的配置，要么使用以注解为主，XML为辅的配置方式进行Bean的配置。

之所以会出现两者共存的情况，主要归结为三个原因：其一，目前绝大多数采用Spring进行开发的项目，几乎都是基于XML配置方式的，Spring在引入注解的同时，必须保证注解能够与XML和谐共存，这是前提；其二，由于注解引入较晚，因此功能也没有发展多年的XML强大，因此，对于复杂的配置，注解还很难独当一面，在一段时间内仍然需要XML的配合才能解决问题。除此之外，Spring的Bean的配置方式与Spring核心模块之间是解耦的，因此，改变配置方式对Spring的框架自身是透明的。Spring可以通过使用Bean后处理器(BeanPostProcessor)非常方便的增加对于注解的支持。这在技术实现上非常容易的事情。

要使用混合配置方式，首先需要判断以哪一种配置方式为主。对这个问题的不同回答将会直接影响到实现的方式。然而大可不必为此伤脑筋，因为不论是以XML为主，还是以注解为主，配置方式都是简单而且容易理解的。这里不存在错误的决定，因为仅仅是表现方式不一样。我们首先假设以XML配置为主的情况。

对于已经存在的大型项目，可能初期是以XML进行Bean配置的，后续逐渐加入了注解的支持，这时我们只需在XML配置文件中将被@Configuration标注的类定义为普通的<bean>，同时注册处理注解的Bean后处理器即可。示例如下：

// 假设存在如下的 @Configuration 类：
 package bookstore.config; 
 import bookstore.dao.*; 
 @Configuration 
 public class MyConfig{ 
 @Bean 
    public UserDao userDao(){ 
        return new UserDaoImpl(); 
    } 
 }

此时，只需在XML中作如下声明即可：

<beans … > 
    ……
    <context:annotation-config /> 
    <bean class=”demo.config.MyConfig”/> 
 </beans>

由于启用了针对注解的Bean后处理器，因此在ApplicationContext解析到MyConfig类时，会发现该类标注了@Configuration注解，随后便会处理该类中标注@Bean的方法，将这些方法的返回值注册为容器总的Bean。

对于以上的方式，如果存在多个标注了@Configuration的类，则需要在XML文件中逐一列出。另一种方式是使用前面提到的自动扫描功能，配置如下：

<context:component-scan base-package=”bookstore.config” />

如此，Spring将扫描所有demo.config包及其子包中的类，识别所有标记了@Component、@Controller、@Service、@Repository注解的类，由于@Configuration注解本身也用@Component标注了，Spring将能够识别出@Configuration标注类并正确解析之。

对于以注解为中心的配置方式，只需使用@ImportResource注解引入存在的XML即可，如下所示：

@Configuration 
 @ImportResource(“classpath:/bookstore/config/spring-beans.xml”) 
 public class MyConfig{ 
……
 } 
 // 容器的初始化过程和纯粹的以配置为中心的方式一致：
 AnnotationConfigApplicationContext ctx = 
              new AnnotationConfigApplicationContext(MyConfig.class); 
……

结束语

从2.0版本开始，Spring的每一次更新都会提供更多新的注解供开发者使用。这满足了注解爱好者的胃口。但是正如前面所说，Spring提供更多的注解并不是为了有朝一日取代XML配置方式，而是为了给开发者多一种选择。两种声明Bean的方式各有特色，XML方式更加灵活，并且发展的相对成熟，这种配置方式为大多数Spring开发者熟悉；注解方式使用起来非常简洁，但是尚处于发展阶段。我们很难说两种配置方式孰优孰劣，但是如果能够灵活搭配两种方式，一定能够进一步提升开发效率。