spring 通过注解装配Bean
使用注解的方式可以减少XML的配置,注解功能更为强大,它既能实现XML的功能,也提供了自动装配的功能,采用了自动装配后,程序员所需要做的决断就少了,更加有利于对程序的开发,这就是“约定优于配置”的开发原则。
在Spring中,它提供了两种方式来让Spring IoC容器发现Bean。
•组件扫描:通过定义资源的方式,让Spring IoC容器扫描对应的包,从而把Bean装配进来。
•自动装配:通过注解定义,使得一些依赖关系可以通过注解完成。
通过扫描和自动装配,大部分的工程都可以用Java配置完成,而不是XML,这样可以有效减少配置和引入大量XML,它解决了在Spring 3之前的版本需要大量的XML配置的问题,这些问题曾被许多开发者诟病。由于目前注解已经成为Spring开发的主流,在之后的章节里,笔者也会以注解的方式为主介绍Spring的开发,但是请注意只是为主,而不是全部以注解的方式去实现。因为不使用XML也存在着一定的弊端,比如系统存在多个公共的配置文件(比如多个properties和XML文件),如果写在注解里,那么那些公共资源的配置就会比较分散了,这样不利于统一的管理,又或者一些类来自于第三方,而不是我们系统开发的配置文件,这时利用XML的方式来完成会更加明确一些,因此目前企业所流行的方式是,以注解为主,以XML为辅,本书的介绍也是如此。
使用@Component装配Bean
@Component(value = "role") public class Role { @Value("1") private Long id; @Value("role_name_1") private String roleName; @Value("role_note_1") private String note; }
•注解@Component代表Spring IoC会把这个类扫描生成Bean实例,而其中的value属性代表这个类在Spring中的id,这就相当于XML方式定义的Bean的id,也可以简写成@Component("role"),甚至直接写成@Component,对于不写的,Spring IoC容器就默认类名,但是以首字母小写的形式作为id,为其生成对象,配置到容器中。
•注解@Value代表的是值的注入,这里只是简单注入一些值,其中id是一个long型,注入的时候Spring会为其转化类型。
现在有了这个类,但是还不能进行测试,因为Spring IoC并不知道需要去哪里扫描对象,这个时候可以使用一个Java Config来去告诉它,如代码清单所示。
代码清单:Java Config类
import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; @Configuration @ComponentScan public class PojoConfig { }
这个类十分简单,几乎没有逻辑,但是要注意两处加粗的代码。
•包名和代码清单的POJO保持一致。
•@ComponentScan代表进行扫描,默认是扫描当前包的路径,POJO的包名和它保持一致才能扫描,否则是没有的。
可以通过Spring定义好的Spring IoC容器的实现类——AnnotationConfigApplicationContext去生成IoC容器了。它十分简单,如代码清单所示。
代码清单:使用注解生成Spring IoC容器
ApplicationContext context = new AnnotationConfigApplicationContext(PojoConfig.class); Role role = context.getBean(Role.class); System.err.println(role.getId());
@ComponentScan存在着两个配置项:第1个是basePackages,它是由base和package两个单词组成的,而package还使用了复数,意味着它可以配置一个Java包的数组,Spring会根据它的配置扫描对应的包和子包,将配置好的Bean装配进来;第2个是basePackageClasses,它由base、package和class三个单词组成的,采用复数,意味着它可以配置多个类,Spring会根据配置的类所在的包,为包和子包进行扫描装配对应配置的Bean。
代码清单:RoleService接口
import com.ssm.chapter10.annotation.pojo.Role; public interface RoleService { public void printRoleInfo(Role role); }
代码清单:RoleServiceImpl类
import org.springframework.stereotype.Component; import com.ssm.chapter10.annotation.pojo.Role; import com.ssm.chapter10.annotation.service.RoleService; @Component public class RoleServiceImpl implements RoleService { // @Override public void printRoleInfo(Role role) { System.out.println("id =" + role.getId()); System.out.println("roleName =" + role.getRoleName()); System.out.println("note =" + role.getNote()); } }
代码清单:配置@ComponentScan制定包扫描
import org.springframework.context.annotation.ComponentScan; import com.ssm.chapter10.annotation.pojo.Role; import com.ssm.chapter10.annotation.service.impl.RoleServiceImpl; @ComponentScan(basePackageClasses = {Role.class, RoleServiceImpl.class}) // @ComponentScan(basePackages = {"com.ssm.chapter10.annotation.pojo", "com.ssm.chapter10.annotation.service"}) // @ComponentScan(basePackages = {"com.ssm.chapter10.annotation.pojo", "com.ssm.chapter10.annotation.service"} //, basePackageClasses = {Role.class, RoleServiceImpl.class}) public class ApplicationConfig { }
•这是对扫描包的定义,可以采用任意一个@ComponentScan去定义,也可以取消代码中的注释。
•如果采用多个@ComponentScan去定义对应的包,但是每定义一个@ComponentScan,Spring就会为所定义的类生成一个新的对象,也就是所配置的Bean将会生成多个实例,这往往不是我们的需要。
•对于已定义了basePackages和basePackageClasses的@ComponentScan,Spring会进行专门的区分,也就是说在同一个@ComponentScan中即使重复定义相同的包或者存在其子包定义,也不会造成因同一个Bean的多次扫描,而导致一次配置生成多个对象。
基于上述的几点,建议不要采用多个@ComponentScan注解进行配置,因为一旦有重复的包和子包就会产生重复的对象,这往往不是真实的需求。对于basePackages和basePackageClasses的选择问题,basePackages的可读性会更好一些,因此在项目中会优先选择使用它,但是在需要大量重构的工程中,尽量不要使用basePackages定义,因为很多时候重构修改包名需要反复地配置,而IDE不会给你任何的提示。而采用basePackageClasses,当你对包移动的时候,IDE会报错提示,并且可以轻松处理这些错误。
代码清单:测试basePackages和basePackageClasses配置
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ApplicationConfig.class); Role role = context.getBean(Role.class); RoleService roleService = context.getBean(RoleService.class); roleService.printRoleInfo(role); context.close();
自动装配——@Autowired
通过学习Spring IoC容器,我们知道Spring是先完成Bean的定义和生成,然后寻找需要注入的资源。也就是当Spring生成所有的Bean后,如果发现这个注解,它就会在Bean中查找,然后找到对应的类型,将其注入进来,这样就完成依赖注入了。所谓自动装配技术是一种由Spring自己发现对应的Bean,自动完成装配工作的方式,它会应用到一个十分常用的注解@Autowired上,这个时候Spring会根据类型去寻找定义的Bean然后将其注入,这里需要留意按类型(Role)的方式。
public interface RoleService2 { public void printRoleInfo(); }
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; import com.ssm.chapter10.annotation.pojo.Role; import com.ssm.chapter10.annotation.service.RoleService2; @Component("RoleService2") public class RoleServiceImpl2 implements RoleService2 { @Autowired private Role role = null; // @Autowired // public void setRole(Role role) { // this.role = role; // } // @Override public void printRoleInfo() { System.out.println("id =" + role.getId()); System.out.println("roleName =" + role.getRoleName()); System.out.println("note =" + role.getNote()); } /**** setter and getter ****/ public Role getRole() { return role; } public void setRole(Role role) { this.role = role; } }
这里的@Autowired注解,表示在Spring IoC定位所有的Bean后,这个字段需要按类型注入,这样IoC容器就会寻找资源,然后将其注入。比如代码清单10-15定义的Role和代码清单10-23定义RoleServiceImpl2的两个Bean,假设将其定义,那么Spring IoC容器会为它们先生成对应的实例,然后依据@Au-towired注解,按照类型找到定义的实例,将其注入。
IoC容器有时候会寻找失败,在默认的情况下寻找失败它就会抛出异常,也就是说默认情况下,Spring IoC容器会认为一定要找到对应的Bean来注入这个字段,有些时候这并不是一个真实的需要,比如日志,有时候我们会觉得这是可有可无的,这个时候可以通过@Autowired的配置项required来改变它,比如@Autowired(required=false)。
正如之前所谈到的在默认情况下是必须注入成功的,所以这里的required的默认值为true。当把配置修改为了false时,就告诉Spring IoC容器,假如在已经定义好的Bean中找不到对应的类型,允许不注入,这样也就没有了异常抛出,只是这样这个字段可能为空,读者要自行校验,以避免发生空指针异常。在大部分的情况下,都不需要这样修改。
@Autowired除可以配置在属性之外,还允许方法配置,常见的Bean的setter方法也可以使用它来完成注入
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ApplicationConfig.class); RoleService2 roleService2 = context.getBean(RoleService2.class); roleService2.printRoleInfo(); context.close();
自动装配的歧义性(@Primary和@Qualifier)
@Autowired注解,它可以完成一些自动装配的功能,并且使用方式十分简单,但是有时候这样的方式并不能使用。这一切的根源来自于按类型的方式,按照Spring的建议,在大部分情况下会使用接口编程,但是定义一个接口,并不一定只有与之对应的一个实现类。换句话说,一个接口可以有多个实现类
import org.springframework.context.annotation.Primary; import org.springframework.stereotype.Component; import com.ssm.chapter10.annotation.pojo.Role; import com.ssm.chapter10.annotation.service.RoleService; @Component("roleService3") // @Primary//方法1 public class RoleServiceImpl3 implements RoleService { // @Override public void printRoleInfo(Role role) { System.out.print("{id =" + role.getId()); System.out.print(", roleName =" + role.getRoleName()); System.out.println(", note =" + role.getNote() + "}"); } }
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.stereotype.Component; import com.ssm.chapter10.annotation.pojo.Role; import com.ssm.chapter10.annotation.service.RoleService; @Component public class RoleController { @Autowired // @Qualifier("roleService3")//方法2 private RoleService roleService = null; public void printRole(Role role) { roleService.printRoleInfo(role); } }
这里的字段roleService是一个RoleService接口类型。RoleService有两个实现类,分别是RoleServiceImpl和RoleServiceImpl3,这个时候Spring IoC容器就会犯糊涂了,它无法判断把哪个对象注入进来,于是就会抛出异常,这样@Autowired注入就失败了。
通过上面的分析,可以知道产生这样的状况是因为它采用的是按类型来注入对象,而在Java中接口可以有多个实现类,同样的抽象类也可以有多个实例化的类,这样就会造成通过类型(bytype)获取Bean的不唯一,从而导致Spring IoC类似于按类型的方法无法获得唯一的实例化类。
为了消除歧义性,Spring提供了两个注解@Primary和@Qualifier,这是两个不同的注解,其消除歧义性的理念不太一样
1. 注解@Primary
注解@Primary代表首要的,当Spring IoC通过一个接口或者抽象类注入对象的时候,由于存在多个实现类或者具体类,就会犯糊涂,不知道采用哪个类注入为好。注解@Primary则是告诉Spring IoC容器,请优先使用该类注入。
2. 注解@Qualifier正如上面所谈及的歧义性,一个重要的原因是Spring在寻找依赖注入的时候采用按类型注入引起的。除了按类型查找Bean,Spring IoC容器最底层的接口BeanFactory,也定义了按名称查找的方法,如果采用名称查找的方法,而不是采用按类型查找的方法,那么不就可以消除歧义性了吗?答案是肯定的,而注解@Qualifier就是这样的一个注解。