使用 Spring 2.5 诠释驱动的 IoC 功能

使用 Spring 2.5 注释驱动的 IoC 功能

概述

注释配置相对于 XML 配置具有很多的优势：

• 它可以充分利用 Java 的反射机制获取类结构信息，这些信息可以有效减少配置的工作。如使用 JPA 注释配置 ORM 映射时，我们就不需要指定 PO 的属性名、类型等信息，如果关系表字段和 PO 属性名、类型都一致，您甚至无需编写任务属性映射信息——因为这些信息都可以通过 Java 反射机制获取。
• 注释和 Java 代码位于一个文件中，而 XML 配置采用独立的配置文件，大多数配置信息在程序开发完成后都不会调整，如果配置信息和 Java 代码放在一起，有助于增强程序的内聚性。而采用独立的 XML 配置文件，程序员在编写一个功能时，往往需要在程序文件和配置文件中不停切换，这种思维上的不连贯会降低开发效率。

  因此在很多情况下，注释配置比 XML 配置更受欢迎，注释配置有进一步流行的趋势。Spring 2.5 的一大增强就是引入了很多注释类，现在您已经可以使用注释配置完成大部分 XML 配置的功能。在这篇文章里，我们将向您讲述使用注释进行 Bean 定义和依赖注入的内容。

  ?

  原来我们是怎么做的

  在使用注释配置之前，先来回顾一下传统上是如何配置 Bean 并完成 Bean 之间依赖关系的建立。下面是 3 个类，它们分别是 Office、Car 和 Boss，这 3 个类需要在 Spring 容器中配置为 Bean：

  Office 仅有一个属性：

  
  清单 1. Office.java
  

  
  Car 拥有两个属性：
  
  清单 2. Car.java
  
  Boss 拥有 Office 和 Car 类型的两个属性：
  
  清单 3. Boss.java
  
  我们在 Spring 容器中将 Office 和 Car 声明为 Bean，并注入到 Boss Bean 中：下面是使用传统 XML 完成这个工作的配置文件 beans.xml：
  
  清单 4. beans.xml 将以上三个类配置成 Bean
  
  当我们运行以下代码时，控制台将正确打出 boss 的信息：
  
  清单 5. 测试类：AnnoIoCTest.java
  ?
  使用 @Autowired 注释
  Spring 2.5 引入了?@Autowired?注释，它可以对类成员变量、方法及构造函数进行标注，完成自动装配的工作。来看一下使用@Autowired?进行成员变量自动注入的代码：
  
  清单 6. 使用 @Autowired 注释的 Boss.java
  
  这样，当 Spring 容器启动时，AutowiredAnnotationBeanPostProcessor?将扫描 Spring 容器中所有 Bean，当发现 Bean 中拥有@Autowired?注释时就找到和其匹配（默认按类型匹配）的 Bean，并注入到对应的地方中去。
  按照上面的配置，Spring 将直接采用 Java 反射机制对 Boss 中的?car?和?office?这两个私有成员变量进行自动注入。所以对成员变量使用?@Autowired?后，您大可将它们的 setter 方法（setCar()?和?setOffice()）从 Boss 中删除。
  当然，您也可以通过?@Autowired?对方法或构造函数进行标注，来看下面的代码：
  
  清单 8. 将 @Autowired 注释标注在 Setter 方法上
  
  当候选 Bean 数目不为 1 时的应对方法
  在默认情况下使用?@Autowired?注释进行自动注入时，Spring 容器中匹配的候选 Bean 数目必须有且仅有一个。当找不到一个匹配的 Bean 时，Spring 容器将抛出?BeanCreationException?异常，并指出必须至少拥有一个匹配的 Bean。我们可以来做一个实验：
  
  清单 10. 候选 Bean 数目为 0 时
  
  由于?office?Bean 被注释掉了，所以 Spring 容器中将没有类型为?Office?的 Bean 了，而 Boss 的?office?属性标注了?@Autowired，当启动 Spring 容器时，异常就产生了。
  当不能确定 Spring 容器中一定拥有某个类的 Bean 时，可以在需要自动注入该类 Bean 的地方可以使用?@Autowired(required = false)，这等于告诉 Spring：在找不到匹配 Bean 时也不报错。来看一下具体的例子：
  
  清单 11. 使用 @Autowired(required = false)
  
  我们在 Spring 容器中配置了两个类型为?Office?类型的 Bean，当对 Boss 的?office?成员变量进行自动注入时，Spring 容器将无法确定到底要用哪一个 Bean，因此异常发生了。
  Spring 允许我们通过?@Qualifier?注释指定注入 Bean 的名称，这样歧义就消除了，可以通过下面的方法解决异常：
  
  清单 13. 使用 @Qualifier 注释指定注入 Bean 的名称
  
  使用 JSR-250 的注释
  Spring 不但支持自己定义的?@Autowired?的注释，还支持几个由 JSR-250 规范定义的注释，它们分别是?@Resource、@PostConstruct以及?@PreDestroy。
  @Resource
  @Resource?的作用相当于?@Autowired，只不过?@Autowired?按 byType 自动注入，面?@Resource?默认按 byName 自动注入罢了。@Resource?有两个属性是比较重要的，分别是 name 和 type，Spring 将?@Resource?注释的 name 属性解析为 Bean 的名字，而 type 属性则解析为 Bean 的类型。所以如果使用 name 属性，则使用 byName 的自动注入策略，而使用 type 属性时则使用 byType 自动注入策略。如果既不指定 name 也不指定 type 属性，这时将通过反射机制使用 byName 自动注入策略。
  Resource 注释类位于 Spring 发布包的 lib/j2ee/common-annotations.jar 类包中，因此在使用之前必须将其加入到项目的类库中。来看一个使用?@Resource?的例子：
  
  清单 16. 使用 @Resource 注释的 Boss.java
  @PostConstruct 和 @PreDestroy
  Spring 容器中的 Bean 是有生命周期的，Spring 允许在 Bean 在初始化完成后以及 Bean 销毁前执行特定的操作，您既可以通过实现 InitializingBean/DisposableBean 接口来定制初始化之后 / 销毁之前的操作方法，也可以通过 <bean> 元素的 init-method/destroy-method 属性指定初始化之后 / 销毁之前调用的操作方法。关于 Spring 的生命周期，笔者在《精通 Spring 2.x—企业应用开发精解》第 3 章进行了详细的描述，有兴趣的读者可以查阅。
  JSR-250 为初始化之后/销毁之前方法的指定定义了两个注释类，分别是 @PostConstruct 和 @PreDestroy，这两个注释只能应用于方法上。标注了 @PostConstruct 注释的方法将在类实例化后调用，而标注了 @PreDestroy 的方法将在类销毁之前调用。
  
  清单 17. 使用 @PostConstruct 和 @PreDestroy 注释的 Boss.java
  ?
  使用 <context:annotation-config/> 简化配置
  Spring 2.1 添加了一个新的 context 的 Schema 命名空间，该命名空间对注释驱动、属性文件引入、加载期织入等功能提供了便捷的配置。我们知道注释本身是不会做任何事情的，它仅提供元数据信息。要使元数据信息真正起作用，必须让负责处理这些元数据的处理器工作起来。
  而我们前面所介绍的?AutowiredAnnotationBeanPostProcessor?和?CommonAnnotationBeanPostProcessor?就是处理这些注释元数据的处理器。但是直接在 Spring 配置文件中定义这些 Bean 显得比较笨拙。Spring 为我们提供了一种方便的注册这些BeanPostProcessor?的方式，这就是 <context:annotation-config/>。请看下面的配置：
  
  清单 19. 调整 beans.xml 配置文件
  
  <context:annotationconfig/> 将隐式地向 Spring 容器注册AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、PersistenceAnnotationBeanPostProcessor?以及equiredAnnotationBeanPostProcessor?这 4 个 BeanPostProcessor。
  在配置文件中使用 context 命名空间之前，必须在 <beans> 元素中声明 context 命名空间。
  回页首
  使用 @Component
  虽然我们可以通过?@Autowired?或?@Resource?在 Bean 类中使用自动注入功能，但是 Bean 还是在 XML 文件中通过 <bean> 进行定义 —— 也就是说，在 XML 配置文件中定义 Bean，通过?@Autowired?或?@Resource?为 Bean 的成员变量、方法入参或构造函数入参提供自动注入的功能。能否也通过注释定义 Bean，从 XML 配置文件中完全移除 Bean 定义的配置呢？答案是肯定的，我们通过 Spring 2.5 提供的?@Component?注释就可以达到这个目标了。
  下面，我们完全使用注释定义 Bean 并完成 Bean 之间装配：
  
  清单 20. 使用 @Component 注释的 Car.java
  
  这里，所有通过 <bean> 元素定义 Bean 的配置内容已经被移除，仅需要添加一行 <context:component-scan/> 配置就解决所有问题了——Spring XML 配置文件得到了极致的简化（当然配置元数据还是需要的，只不过以注释形式存在罢了）。<context:component-scan/> 的 base-package 属性指定了需要扫描的类包，类包及其递归子包中所有的类都会被处理。
  <context:component-scan/> 还允许定义过滤器将基包下的某些类纳入或排除。Spring 支持以下 4 种类型的过滤方式，通过下表说明：
  
  表 1. 扫描过滤方式
  过滤器类型说明注释假如 com.baobaotao.SomeAnnotation 是一个注释类，我们可以将使用该注释的类过滤出来。类名指定通过全限定类名进行过滤，如您可以指定将 com.baobaotao.Boss 纳入扫描，而将 com.baobaotao.Car 排除在外。正则表达式通过正则表达式定义过滤的类，如下所示： com\.baobaotao\.Default.*AspectJ 表达式通过 AspectJ 表达式定义过滤的类，如下所示： com. baobaotao..*Service+
  下面是一个简单的例子：
  
  值得注意的是 <context:component-scan/> 配置项不但启用了对类包进行扫描以实施注释驱动 Bean 定义的功能，同时还启用了注释驱动自动注入的功能（即还隐式地在内部注册了?AutowiredAnnotationBeanPostProcessor?和CommonAnnotationBeanPostProcessor），因此当使用 <context:component-scan/> 后，就可以将 <context:annotation-config/> 移除了。
  默认情况下通过?@Component?定义的 Bean 都是 singleton 的，如果需要使用其它作用范围的 Bean，可以通过?@Scope?注释来达到目标，如以下代码所示：
  
  清单 24. 通过 @Scope 指定 Bean 的作用范围
  回页首
  采用具有特殊语义的注释
  Spring 2.5 中除了提供?@Component?注释外，还定义了几个拥有特殊语义的注释，它们分别是：@Repository、@Service?和@Controller。在目前的 Spring 版本中，这 3 个注释和?@Component?是等效的，但是从注释类的命名上，很容易看出这 3 个注释分别和持久层、业务层和控制层（Web 层）相对应。虽然目前这 3 个注释和?@Component?相比没有什么新意，但 Spring 将在以后的版本中为它们添加特殊的功能。所以，如果 Web 应用程序采用了经典的三层分层结构的话，最好在持久层、业务层和控制层分别采用@Repository、@Service?和?@Controller?对分层中的类进行注释，而用?@Component?对那些比较中立的类进行注释。
  回页首
  注释配置和 XML 配置的适用场合
  是否有了这些 IOC 注释，我们就可以完全摒除原来 XML 配置的方式呢？答案是否定的。有以下几点原因：
  注释配置不一定在先天上优于 XML 配置。如果 Bean 的依赖关系是固定的，（如 Service 使用了哪几个 DAO 类），这种配置信息不会在部署时发生调整，那么注释配置优于 XML 配置；反之如果这种依赖关系会在部署时发生调整，XML 配置显然又优于注释配置，因为注释是对 Java 源代码的调整，您需要重新改写源代码并重新编译才可以实施调整。
  如果 Bean 不是自己编写的类（如?JdbcTemplate、SessionFactoryBean?等），注释配置将无法实施，此时 XML 配置是唯一可用的方式。
  注释配置往往是类级别的，而 XML 配置则可以表现得更加灵活。比如相比于?@Transaction?事务注释，使用 aop/tx 命名空间的事务配置更加灵活和简单。
  所以在实现应用中，我们往往需要同时使用注释配置和 XML 配置，对于类级别且不会发生变动的配置可以优先考虑注释配置；而对于那些第三方类以及容易发生调整的配置则应优先考虑使用 XML 配置。Spring 会在具体实施 Bean 创建和 Bean 注入之前将这两种配置方式的元信息融合在一起。
  
  小结
  Spring 在 2.1 以后对注释配置提供了强力的支持，注释配置功能成为 Spring 2.5 的最大的亮点之一。合理地使用 Spring 2.5 的注释配置，可以有效减少配置的工作量，提高程序的内聚性。但是这并不意味着传统 XML 配置将走向消亡，在第三方类 Bean 的配置，以及那些诸如数据源、缓存池、持久层操作模板类、事务管理等内容的配置上，XML 配置依然拥有不可替代的地位。