Sping注解详解Word格式.docx

Sping注解详解Word格式.docx

《Sping注解详解Word格式.docx》由会员分享，可在线阅读，更多相关《Sping注解详解Word格式.docx（11页珍藏版）》请在冰点文库上搜索。

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

　<

beans　…　>

　　……　

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　...>

component-scan　

　base-package="

a.b"

　name-generator="

a.SimpleNameGenerator"

/>

　　与通过XML配置的SpringBean一样，通过上述注解标识的Bean，其默认作用域是"

singleton"

，为了配合这四个注解，在标注Bean的同时能够指定Bean的作用域，Spring2.5引入了@Scope注解。

使用该注解时只需提供作用域的名称就行了，如下所示：

@Scope（"

prototype"

）　

@Repository　

public　class　Demo　{　…　}　

　　如果你想提供一个自定义的作用域解析策略而不使用基于注解的方法，只需实现ScopeMetadataResolver接口，确认包含一个默认的没有参数的构造方法。

然后在配置扫描器时提供全限定类名：

component-scan　base-package="

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中增加如下一行：

annotation-config　/>

　　比较上述三种指定生命周期回调方法的方式，第一种是不建议使用的，不但其用法不如后两种方式灵活，而且无形中增加了代码与框架的耦合度。

后面两种方式开发者可以根据使用习惯选择其中一种，但是最好不要混合使用，以免增加维护的难度。

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

　　依赖检查的作用是，判断给定Bean的相应Setter方法是否都在实例化的时候被调用了。

而不是判断字段是否已经存在值了。

Spring进行依赖检查时，只会判断属性是否使用了Setter注入。

如果某个属性没有使用Setter注入，即使是通过构造函数已经为该属性注入了值，Spring仍然认为它没有执行注入，从而抛出异常。

另外，Spring只管是否通过Setter执行了注入，而对注入的值却没有任何要求，即使注入的<

null/>

，Spring也认为是执行了依赖注入。

　　<

标签提供了dependency-check属性用于进行依赖检查。

该属性的取值包括以下几种：

　　none--默认不执行依赖检查。

可以在<

beans>

标签上使用default-dependency-check属性改变默认值。

　　simple--对原始基本类型和集合类型进行检查。

　　objects--对复杂类型进行检查（除了simple所检查类型之外的其他类型）。

　　all--对所有类型进行检查。

　　旧版本使用dependency-check在配置文件中设置，缺点是粒度较粗。

使用Spring2.0提供的@Required注解，提供了更细粒度的控制。

@Required注解只能标注在Setter方法之上。

因为依赖注入的本质是检查Setter方法是否被调用了，而不是真的去检查属性是否赋值了以及赋了什么样的值。

如果将该注解标注在非setXxxx（）类型的方法则被忽略。

　　为了让Spring能够处理该注解，需要激活相应的Bean后处理器。

要激活该后处理器，只需在XML中增加如下一行即可。

annotation-config/>

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

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

　　自动装配是指，Spring在装配Bean的时候，根据指定的自动装配规则，将某个Bean所需要引用类型的Bean注入进来。

元素提供了一个指定自动装配类型的autowire属性，该属性有如下选项：

　　no--显式指定不使用自动装配。

　　byName--如果存在一个和当前属性名字一致的Bean，则使用该Bean进行注入。

如果名称匹配但是类型不匹配，则抛出异常。

如果没有匹配的类型，则什么也不做。

　　byType--如果存在一个和当前属性类型一致的Bean（相同类型或者子类型），则使用该Bean进行注入。

byType能够识别工厂方法，即能够识别factory-method的返回类型。

如果存在多个类型一致的Bean，则抛出异常。

constructor--与byType类似，只不过它是针对构造函数注入而言的。

如果当前没有与构造函数的参数类型匹配的Bean，则抛出异常。

使用该种装配模式时，优先匹配参数最多的构造函数。

　　autodetect--根据Bean的自省机制决定采用byType还是constructor进行自动装配。

如果Bean提供了默认的构造函数，则采用byType；

否则采用constructor进行自动装配。

　　当使用byType或者constructor类型的自动装配的时候，自动装配也支持引用类型的数组或者使用了泛型的集合，这样，Spring就会检查容器中所有类型匹配的Bean，组成集合或者数组后执行注入。

对于使用了泛型的Map类型，如果键是String类型，则Spring也会自动执行装配，将所有类型匹配的Bean作为值，Bean的名字作为键。

　　我们可以给<

增加default-autowire属性，设置默认的自动封装策略。

默认值为"

no"

。

如果使用自动装配的同时，也指定了property或者constructor-arg标签，则显式指定的值将覆盖自动装配的值。

目前的自动封装不支持简单类型，比如基本类型、String、Class，以及它们的数组类型。

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

解决方法有如下几种：

　　取消该Bean的自动装配特性，使用显式的注入。

我们可能不希望某个Bean被当作其他Bean执行自动封装时的候选对象，我们可以给该<

增加autowire-candidate="

false"

（autowire-candidate属性和autowire属性相互独立，互不相干。

某个Bean可以将autowire-candidate设置为false，同时使用autowire特性。

）另外，我们可以设置<

的default-autowire-candidates属性，可以在该属性中指定可以用于自动装配候选Bean的匹配模式，比如default-autowire-candidates="

*serv,*dao"

，这表示所有名字以serv或者dao结尾的Bean被列为候选，其他则忽略，相当于其他Bean都指定为autowire-candidate="

，此时可以显式为<

指定autowire-candidate="

true"

在<

上指定的设置要覆盖<

上指定的设置。

　　如果在多个类型相同的Bean中有首选的Bean，那么可以将该<

的primary属性设置为"

，这样自动装配时便优先使用该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标注放置在方法声明上面，但是推荐放置在参数前面），举例如下：

public　void　sayHello（@Qualifier（"

）Person　p,String　name）{}　

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

bean　id="

person"

　class="

footmark.spring.Person"

>

qualifier　value="

　　如果没有明确指定Bean的qualifier名字，那么默认名字就是Bean的名字。

通常，qualifier应该是有业务含义的，例如"

domain"

，"

persistent"

等，而不应该是类似"

方式。

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

　　最后，配置文件中需要指定每一个自定义注解的属性值。

我们可以使用<

meta>

标签来代替<

qualifier/>

标签，如果<

标签和<

标签同时出现，那么优先使用<

qualifier>

标签。

如果没有<

标签，那么会用<

提供的键值对来封装<

bean　class="

footmark.HelloWorld"

qualifier　type="

MovieQualifier"

attribute　key="

format"

　value="

VHS"

genre"

Comedy"

/qualifier>

meta　key="

DVD"

Action"

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

　　如果@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等价，并且不被忽略。

的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。

从名字便可以看出，它们是为注解而生，直接依赖于注解作为容器配置信息来源