spring隐式的bean发现机制和自动化装配，基于注解的自动化装配

爱被打了一巴掌 2023-02-17 11:04 23阅读 0赞

### spring隐式的bean发现机制和自动化转配，基于注解的自动化装配 ###

*  自动化装配步骤
 *  自动化扫描常用注解
 *   *  Spring注解@Component、@Repository、@Service、@Controller区别
     *  为组件扫描的bean命名@Component，@Repository、@Service 和 @Controller
 *  设置组件扫描的基础包@ComponentScan
 *  自动装配@Autowired
 *   *  处理自动装配的奇异性

# 自动化装配步骤 #

尽管显示装配技术非常有用，但是在便利性方面，最强大的还是spring的自动化配置。  
spring从两个角度来实现自动化装配：

*  组件扫描(component scanning)：Spring会自动发现应用上下文中所创建的bean。
 *  自动装配(autowiring)：Spring自动满足bean之间的依赖。

组件扫描和自动装配组合在一起就能发挥出强大的为力，他们能够将你的显示配置降低到最少。

# 自动化扫描常用注解 #

在学习自动化装配Bean之前我们先来了解几个常用的注解

*  @Configuration  
    如果用@Configuration注解加到某个类的上面，则表明这个类是一个配置类，该类应该包含在Spring应用上下文中如何创建Bean的细节。
 *  @ComponentScan  
    此注解用于JavaConfig的配置类中，能够在Spring中启用组件扫描，默认会扫描与配置类相同的包(就是扫描配置类所在的包内有所有具有添加了诸如Component注解的类，其他的包不会进行扫描，但是可以通过属性配置)。  
    在xml中也可以通过配置来进行自动化扫描

<context:component-scan bese-package="*******">
    	
    	或者在applicationContext.xml中如下配置
    	
    	<context:component-scan base-package="com.logRightsCheck">
            <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
        </context:component-scan>
        
        或者在springmvc-servlet.xml中如下配置
        
        <context:component-scan base-package="com.logRightsCheck.web">
            <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
        </context:component-scan>

*  @Component  
    @Component注解表明该类会作为组件类，并告知Spring要为这个类创建Bean。
 *  @ContextConfiguration(classes=JavaConfig类.class)  
    此注解会告诉它需要在JavaConfig类中加载配置。应为JavaConfig配置类中包含了@ComponentScan注解。  
    此注解一般用于在测试类中使用。告诉测试类到哪个配置类中去加载配置，配置类使用自动化扫描机制，把组件类扫描到容器中，然后测试类就可以从容器中获取对象了。
 *  @Autowired  
    此注解用于Spring容器自动在Spring上下文中将其创建的Bean注入到当前类中，供当前类使用。

## Spring注解@Component、@Repository、@Service、@Controller区别 ##

另外还有三个注解需要注意：

*  @Service
 *  @Controller
 *  @Repository

spring 2.5 中除了提供 @Component 注释外，还定义了几个拥有特殊语义的注释，它们分别是：@Repository、@Service 和 @Controller。在目前的 Spring 版本中，这 3 个注释和 @Component 是等效的，但是从注释类的命名上，很容易看出这 3 个注释分别和持久层、业务层和控制层（Web 层）相对应。虽然目前这 3 个注释和 @Component 相比没有什么新意，但 Spring 将在以后的版本中为它们添加特殊的功能。所以，如果Web 应用程序采用了经典的三层分层结构的话，最好在持久层、业务层和控制层分别采用@Repository、@Service 和 @Controller 对分层中的类进行注释，而用 @Component 对那些比较中立的类进行注释。

在一个稍大的项目中，通常会有上百个组件，如果这些组件采用xml的bean定义来配置，显然会增加配置文件的体积，查找以及维护起来也不太方便。 Spring2.5为我们引入了组件自动扫描机制，他可以在类路径底下寻找标注了@Component,@Service,@Controller,  
@Repository注解的类，并把这些类纳入进spring容器中管理。

## 为组件扫描的bean命名@Component，@Repository、@Service 和 @Controller ##

Spring应用上下文中所有的bean都会给定一个ID。如果我们没有明确的为Bean设置ID，但Spring会根据类名为其指定一个ID。具体来讲，这个Bean所给定的ID为类名的首字母小写(如果该类名为UserServiceImpl，则这个Bean的ID则为userServiceImpl)。如果想为这个Bean设置不同的ID，你所需要做的就是将期望的ID作为值传递给@Component注解。例如:

@Component("userServiceImplTest")
    public class UserServiceImpl implemets UserService{ 
    	......
    }

@Component，@Repository、@Service 都可以定义别名@Controller使用很少使用别名

# 设置组件扫描的基础包@ComponentScan #

如果不为@ComponentScan设置任何属性。这以为着，按照默认规则，他会以配置配置类所在的包作为基础包(base package)来扫描组件。但是如果你想扫描不同的包怎么办呢？或者如果你想扫描多个基础包，那又该怎么办呢？  
 有一个原因会促使我们明确地设置基础包，那就是我们要将配置类放在单独的包中，使其与其它的应用代码分开来。如果是这样的话，那默认的基础包就不能满足要求了。  
为了指定不同的基础包，你所要做的就是在@ComponentScan的value属性中指明包的名称。

例如

@Configuration
    @ComponentScan(value="userObject")
    public class UserObjectConfig(){ 
    	.....
    }

如果你想更加清晰第表名你所设置的是基础包，那么你可以通过basePackage属性进行配置：

@Configuration
    @ComponentScan(basePackages="userObject")
    public class UserObjectConfig(){ 
    	.....
    }

也可以设置多个基础包：

@Configuration
    @ComponentScan(basePackages={ "userObject","userRoleObject"})
    public class UserObjectConfig(){ 
    	.....
    }

value属性和basePackages的作用是一样的。都是用于指定创建容器时要扫描的包。我们使用此注解就等同于在xml中配置了

<context:component-scan base-package="userObject"/>

在上面的例子中，所设置的基础包是以String类型表示的。我认为这是可以的，  
但这种方法是类型不安全(not type-safe)的。如果你重构代码的话，那么所指定的基础  
包可能就会出现错误了。  
除了将包设置为简单的String类型之外，@ComponentScan 还提供了另外一种方  
法，那就是将其指定为包中所包含的类或接口:

@Configuration
    @ComponentScan(basePackageClasses={ UserService.class,UserRoleServiceImpl.class})
    public class UserObjectConfig(){ 
    	.....
    }

可以看到，basePackages属性被替换成了basePackageClasses。同时，我们不是再使用String类型的名称来指定包，为basePackageClasses属性所设置的数组中包含了类。这些类所在的包将会作为组件扫描的基础包。尽管在样例中，我为basePackageClasses设置的是组件类，但是你可以考虑在包中创建一个用来进行扫描的空标记接口(marker interface)。通过标记接口的方式，你依然能够保持对重构友好的接口引用，但是可以避免引用任何实际的应用程序代码(在稍后重构中，这些应用代码有可能会从想要扫描的包中移除掉)。

# 自动装配@Autowired #

在你的应用程序中，如果所有的对象都是独立的，彼此之间没有任何依赖，那么你所需要的可能就是组件扫描而已。但是，很多对象会依赖其他的对象才能完成任务。这样的话，我们就需要有一种方法能够将组件扫描得到的bean和它们的依赖装配在一起。 要完成这项任务，我们需要了解一下Spring自动化配置的另外一方面内容，那就是自动装配。  
 简单来说，自动装配就是让Spring自动满足bean依赖的一种方法，在满足依赖的过程中，会在Spring应用上下文中寻找匹配某个bean需求的其他bean。为了声明要进行自动装配，我们可以借助Spring的@Autowired注解。

比方说，考虑程序清单2.6中的CDPlayer类。它的构造器上添加了@Autowired注解，这表明当Spring创建CDPlayer bean 的时候，会通过这个构造器来进行实例化并且会传入一个可设置给CompactDisc类型的bean。

@Component
    public class CDPlayer impl ements MediaPlayer { 
    	private CompactDisc cd;
    
    	@Autowired
    	public CDPlayer (CompactDisc cd) { 
    		this.cd = cd;
    	}
    
    	public void play() { 
    		cd.play() ;
    	}
    }

@Autowired注解不仅能够用在构造器上，还能用在属性的Setter方法上。比如说，如果CDPlayer有一个setCompactDisc方法,那么可以采用如下的注解形式进行自  
动装配:

@Autowired
    public void setCompactDisc(CompactDisc cd) { 
    	this.cd = cd;
    }

实际上，Setter 方法并没有什么特殊之处。@Autowired 注解可以用在类的任何方法上。假设CDPlayer类有一个insertDisc() 方法，那么@Autowired能够像在setCompactDisc().上那样，发挥完全相同的作用:

@Autowired
    public void insertDisc (CompactDisc cd) { 
    	this.cd = cd;
    }

不管是构造器、Setter 方法还是其他的方法，Spring 都会尝试满足方法参数上所声明的依赖。假如有且只有一个bean匹配依赖需求的话，那么这个bean将会被装配进来。如果没有匹配的bean,那么在应用上下文创建的时候，Spring 会抛出一个异常。为了避免异常的出现，你可以将@Autowired的required属性设置为false:

@Autowired(required=false)
    public CDPlayer(CompactDisc cd) { 
    	this.cd = cd;
    }

将required属性设置为false时，Spring 会尝试执行自动装配，但是如果没有匹配的bean的话，Spring 将会让这个bean处于未装配的状态。但是，把required属性设置为false时，你需要谨慎对待。如果在你的代码中没有进行null 检查的话，这个处于未装配状态的属性有可能会出现NullPointerException.  
 如果有多个bean都能满足依赖关系的话，Spring 将会抛出一个异常，表明没有明确指定要选择哪个bean进行自动装配。这叫做自动装配中的歧义性。  
 @Autowired是Spring特有的注解。如果你不愿意在代码中到处使用Spring的特  
定注解来完成自动装配任务的话，那么你可以考虑将其替换为@Inject:

@Inject
    public CDPlayer(CompactDisc cd) { 
    	this.cd = cd;
    }

@Inject注解来源于Java依赖注人规范，该规范同时还为我们定义了@Named注解。在自动装配中，Spring 同时支持@Inject和@Autowired。 尽管@Inject和  
@Autowired之间有着些细微的差别，但是在大多数场景下，它们都是可以互相替换的。  
在@Inject和@Autowired中，我没有特别强烈的偏向性。实际上，在有的项目中，我会发现我同时使用了这两个注解。

## 处理自动装配的奇异性 ##

在spring的bean匹配所需的结果时，自动装配才是有效的。如果不仅有一个bean能够匹配结构的话，这种奇异性会阻碍Spring自动装配属性，构造器参数或方法参数。  
比如：  
有三个实现类都实现了UserService接口

@Service
    public class UserServiceImpl1 implements UserService{ 
    	...
    }
    @Service
    public class UserServiceImpl2 implements UserService{ 
    	...
    }
    @Service
    public class UserServiceImpl3 implements UserService{ 
    	...
    }

然后Spring自动装配到某个方式时如下使用

@Autowired
    public void setUserInfo(UserService userService){ 
    	this.userService = userService;
    }

当spring试图自动装配setUserInfo()中的userService参数时，并没有唯一，无歧义的可选值。Spring此时别无他法，只好抛出异常。

解决办法：

*  标识首选的Bean–>@Primary注解  
    在声明bean的时候，通过将其中-一个可选的bean设置为首选(primary) bean能够避免自动装配时的歧义性。当遇到歧义性的时候，Spring 将会使用首选的bean,而不是其他可选的bean。实际上，你所声明就是“最喜欢”的bean。

@Service
    @Primary
    public class UserServiceImpl1 implements UserService{ 
    	...
    }
    @Service
    public class UserServiceImpl2 implements UserService{ 
    	...
    }
    @Service
    public class UserServiceImpl3 implements UserService{ 
    	...
    }

如果你使用XML配置bean的话，同样可以实现这样的功能。<bean>元素有一个  
primary属性用来指定首选的bean:

不管你采用什么方式来标示首选bean,效果都是一样的， 都是告诉Spring 在遇到歧  
义性的时候要选择首选的bean。  
但是，如果你标示了两个或更多的首选bean,那么它就无法正常工作了。比如，假  
设UserServiceImpl2类如下所示:

@Service
    @Primary
    public class UserServiceImpl1 implements UserService{ 
    	...
    }
    @Service
    @Primary
    public class UserServiceImpl2 implements UserService{ 
    	...
    }
    @Service
    public class UserServiceImpl3 implements UserService{ 
    	...
    }

现在，有两个首选的UserService bean: UserServiceImpl21和UserServiceImpl2 。这带来了新的歧义性问题。就像Spring 无法从多个可选的bean中做出选择一样，它也无法从多个首选的bean中做出选择。显然，如果不止一个bean被设置成了首选bean，那实际上也就是没有首选bean了。就解决歧义性问题而言，限定符是一种更为强大的机制，下面就将对其进行介绍。

*  限定自动装配的Bean–>@Qualifier注解  
    @Qualifier注解是使用限定符的主要方式。它可以与@Autowired和@Inject  
    协同使用，在注人的时候指定想要注人进去的是哪个bean。 例如，我们想要确保要将  
    userServiceImpl1注人到setUserInfo()之中:

@Autowired
    @Qualifier("userServiceImpl1")
    public void setUserInfo(UserService userService){ 
    	this.userService = userService;
    }

这是使用限定符的最简单的例子。为@Qualifier注解所设置的参数就是想要注人的bean的ID。所有使用@Component注解声明的类都会创建为bean，并且bean的ID为首字母变为小写的类名。因此，@Qualifier (“userServiceImpl1”)指向的是组件扫描时所创建的bean,并且这个bean是UserServiceImpl1类的实例。  
 实际上，还有一点需要补充一下。更准确地讲, @Qualifier (“userServiceImpl1”)所引用的bean要具有String类型的“userServiceImpl1” 作为限定符。如果没有指定其他的限定符的话，所有的bean都会给定一个默认的限定符，这个限定符与bean的ID相同。因此，框架会将具有“userServiceImpl1” 限定符的bean注人到setUserInfo()方法中。这恰巧就是ID为userServiceImpl1的bean,它是UserServiceImpl1类在组件扫描的时候创建的。基于默认的bean ID作为限定符是非常简单的，但这有可能会引人一-些问题。如果你重构了userServiceImpl1类，将其重命名为UserServiceImpl4的话，那此时会发生什么情况呢?如果这样的话，bean的ID和默认的限定符会变为userServiceImpl4,这就无法匹配setUserInfo() 方法中的限定符。自动装配会失败。这里的问题在于setUserInfo()方法上所指定的限定符与要注人的bean的名称是紧耦合的。对类名称的任意改动都会导致限定符失效。  
为了解决这个问题，则可以创建自定义的限定符  
 我们可以为bean设置自己的限定符，而不是依赖于将bean ID作为限定符。在这里  
所需要做的就是在bean声明上添加@Qualifier注解。例如，它可以与@Component  
组合使用，如下所示:

@Service
    @Qualifier("userServiceImplOne")
    public class UserServiceImpl1 implements UserService{ 
    	...
    }

在这种情况下，userServiceImplOne限定符分配给了UserServiceImpl1 bean。 因为它没有耦合类名，因此你可以随意重构UserServiceImpl1 的类名，而不必担心会破坏自动装配。在注人的地方，只要引用userServiceImplOne限定符就可以了:

@Autowired
    @Qualifier("userServiceImplOne")
    public void setUserInfo(UserService userService){ 
    	this.userService = userService;
    }

链接:[《spring隐式的bean发现机制和自动化装配源码案例》][spring_bean]

[spring_bean]: https://blog.csdn.net/summer_style/article/details/106734364