详解 spring 3

《详解 spring 3》由会员分享，可在线阅读，更多相关《详解 spring 3（13页珍藏版）》请在金锄头文库上搜索。

1、详解详解 SpringSpring 3.03.0 基于基于 AnnotationAnnotation 的的 依赖注入实现依赖注入实现张 建平, 项目经理, iSoftStone Co.,Ltd简介：简介： Spring 的依赖配置方式与 Spring 框架的内核自身是松耦合设计的。 然而，直到 Spring 3.0 以前，使用 XML 进行依赖配置几乎是唯一的选择。 Spring 3.0 的出现改变了这一状况，它提供了一系列的针对依赖注入的注解， 这使得 Spring IoC 在 XML 文件之外多了一种可行的选择。本文将详细介绍如 何使用这些注解进行依赖配置的管理。使用 Repository

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

3、okstore.dao; Repository public class UserDaoImpl implements UserDao / 其次，在 XML 配置文件中启动 Spring 的自动扫描功能如此，我们就不再需要在 XML 中显式使用 进行 Bean 的配置。 Spring 在容器初始化时将自动扫描 base-package 指定的包及其子包下的所有 class 文件，所有标注了 Repository 的类都将被注册为 Spring Bean。为什么 Repository 只能标注在 DAO 类上呢？这是因为该注解的作用不只是 将类识别为 Bean，同时它还能将所标注的类中抛出的数据

4、访问异常封装为 Spring 的数据访问异常类型。 Spring 本身提供了一个丰富的并且是与具体的 数据访问技术无关的数据访问异常结构，用于封装不同的持久层框架抛出的异 常，使得异常独立于底层的框架。Spring 2.5 在 Repository 的基础上增加了功能类似的额外三个注解： Component、Service、Constroller，它们分别用于软件系统的不同层次：Component 是一个泛化的概念，仅仅表示一个组件 (Bean) ，可以作用 在任何层次。 Service 通常作用在业务层，但是目前该功能与 Component 相同。 Constroller 通常作用在控制层，

5、但是目前该功能与 Component 相同。通过在类上使用 Repository、Component、Service 和 Constroller 注解， Spring 会自动创建相应的 BeanDefinition 对象，并注册到 ApplicationContext 中。这些类就成了 Spring 受管组件。这三个注解除了作 用于不同软件层次的类，其使用方式与 Repository 是完全相同的。另外，除了上面的四个注解外，用户可以创建自定义的注解，然后在注解上标 注 Component，那么，该自定义注解便具有了与所 Component 相同的功能。 不过这个功能并不常用。当一个 Bean

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

7、与通过 XML 配置的 Spring Bean 一样，通过上述注解标识的 Bean，其默认作 用域是“singleton“，为了配合这四个注解，在标注 Bean 的同时能够指定 Bean 的作用域，Spring 2.5 引入了 Scope 注解。使用该注解时只需提供作 用域的名称就行了，如下所示：Scope(“prototype“) Repository public class Demo 如果你想提供一个自定义的作用域解析策略而不使用基于注解的方法，只需实 现 ScopeMetadataResolver 接口，确认包含一个默认的没有参数的构造方法。 然后在配置扫描器时提供全限定类名：使用 P

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

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

10、 文件中使用 的 init-method 和 destroy-method 属性指定初始化之后和销毁之前的回调方法，代码无需实现任何接口。这两个 属性的取值是相应 Bean 类中的初始化和销毁方法，方法名任意，但是方法不 能有参数。示例如下：Spring 2.5 在保留以上两种方式的基础上，提供了对 JSR-250 的支持。JSR- 250 规范定义了两个用于指定声明周期方法的注解：PostConstruct 和 PreDestroy。这两个注解使用非常简单，只需分别将他们标注于初始化之后执 行的回调方法或者销毁之前执行的回调方法上。由于使用了注解，因此需要配 置相应的 Bean 后处理器，亦

11、即在 XML 中增加如下一行：比较上述三种指定生命周期回调方法的方式，第一种是不建议使用的，不但其 用法不如后两种方式灵活，而且无形中增加了代码与框架的耦合度。后面两种 方式开发者可以根据使用习惯选择其中一种，但是最好不要混合使用，以免增 加维护的难度。使用 Required 进行 Bean 的依赖检查依赖检查的作用是，判断给定 Bean 的相应 Setter 方法是否都在实例化的时 候被调用了。而不是判断字段是否已经存在值了。Spring 进行依赖检查时，只 会判断属性是否使用了 Setter 注入。如果某个属性没有使用 Setter 注入， 即使是通过构造函数已经为该属性注入了值，Spri

12、ng 仍然认为它没有执行注入， 从而抛出异常。另外，Spring 只管是否通过 Setter 执行了注入，而对注入的 值却没有任何要求，即使注入的 ，Spring 也认为是执行了依赖注入。标签提供了 dependency-check 属性用于进行依赖检查。该属性的取值 包括以下几种：none - 默认不执行依赖检查。可以在 标签上使用 default- dependency-check 属性改变默认值。 simple - 对原始基本类型和集合类型进行检查。 objects - 对复杂类型进行检查（除了 simple 所检查类型之外的其他 类型）。 all - 对所有类型进行检查。 旧版本使用

13、dependency-check 在配置文件中设置，缺点是粒度较粗。使用 Spring2.0 提供的 Required 注解，提供了更细粒度的控制。Required 注解 只能标注在 Setter 方法之上。因为依赖注入的本质是检查 Setter 方法是否 被调用了，而不是真的去检查属性是否赋值了以及赋了什么样的值。如果将该 注解标注在非 setXxxx() 类型的方法则被忽略。为了让 Spring 能够处理该注解，需要激活相应的 Bean 后处理器。要激活该 后处理器，只需在 XML 中增加如下一行即可。当某个被标注了 Required 的 Setter 方法没有被调用，则 Spring 在

14、解析的 时候会抛出异常，以提醒开发者对相应属性进行设置。使用 Resource、Autowired 和 Qualifier 指定 Bean 的自动装配策略自动装配是指，Spring 在装配 Bean 的时候，根据指定的自动装配规则，将某 个 Bean 所需要引用类型的 Bean 注入进来。 元素提供了一个指定自动 装配类型的 autowire 属性，该属性有如下选项：no - 显式指定不使用自动装配。 byName - 如果存在一个和当前属性名字一致的 Bean，则使用该 Bean 进行注入。如果名称匹配但是类型不匹配，则抛出异常。如果没有匹配 的类型，则什么也不做。 byType - 如果存

15、在一个和当前属性类型一致的 Bean ( 相同类型或者 子类型 )，则使用该 Bean 进行注入。byType 能够识别工厂方法，即能 够识别 factory-method 的返回类型。如果存在多个类型一致的 Bean， 则抛出异常。如果没有匹配的类型，则什么也不做。 constructor - 与 byType 类似，只不过它是针对构造函数注入而言的。 如果当前没有与构造函数的参数类型匹配的 Bean，则抛出异常。使用该 种装配模式时，优先匹配参数最多的构造函数。 autodetect - 根据 Bean 的自省机制决定采用 byType 还是 constructor 进行自动装配。如果 B

16、ean 提供了默认的构造函数，则采 用 byType；否则采用 constructor 进行自动装配。 当使用 byType 或者 constructor 类型的自动装配的时候，自动装配也支持引 用类型的数组或者使用了泛型的集合，这样，Spring 就会检查容器中所有类型 匹配的 Bean，组成集合或者数组后执行注入。对于使用了泛型的 Map 类型， 如果键是 String 类型，则 Spring 也会自动执行装配，将所有类型匹配的 Bean 作为值，Bean 的名字作为键。我们可以给 增加 default-autowire 属性，设置默认的自动封装策略。 默认值为“no“。如果使用自动装配的同时，也指定了 property 或者 constructor-arg 标签，则显式指定的值将覆盖自动装配的值。目前的自动封 装不支持简单类型，比如基本类型、String、Cl