Java中@Resource注解和@Autowired注解(spring中的@Autowired)

一时失言乱红尘 2022-09-25 10:29 306阅读 0赞

1、@Autowired与@Resource都可以用来装配bean. 都可以写在字段上,或写在setter方法上。

2、@Autowired默认按类型装配（这个注解是属业spring的），默认情况下必须要求依赖对象必须存在，如果要允许null 值，可以设置它的required属性为false，如：@Autowired(required=false) ，如果我们想使用名称装配可以结合@Qualifier注解进行使用，如下：

@Autowired() @Qualifier("baseDao")   
    private BaseDao baseDao;

3、@Resource（这个注解属于J2EE的），默认安照名称进行装配，名称可以通过name属性进行指定，   
如果没有指定name属性，当注解写在字段上时，默认取字段名进行按照名称查找， 如果注解写在setter方法上默认取属性名进行装配。  当找不到与名称匹配的bean时才按照类型进行装配。但是需要注意的是，如果name属性一旦指定，就只会按照名 称进行装配。

@Resource(name="baseDao")   
    private BaseDao baseDao;

我喜欢用 @Resource注解在字段上，且这个注解是属于J2EE的，减少了与spring的耦合。最重要的 这样代码看起就比较优雅。

@Resource 注解被用来激活一个命名资源（named resource）的依赖注入，在JavaEE应用程序中，该注解被典型地转换为绑定于JNDI context中的一个对象。 Spring确实支持使用@Resource通过JNDI lookup来解析对象，默认地，拥有与@Resource注解所提供名字相匹配的“bean name（bean名字）”的Spring管理对象会被注入。 在下面的例子中，Spring会向加了注解的setter方法传递bean名为“dataSource”的Spring管理对象的引用。  
@Resource(name="dataSource") public void setDataSource(DataSource dataSource) \{ this.dataSource = dataSource; \}  
直接使用@Resource注解一个域（field）同样是可能的。通过不暴露setter方法，代码愈发紧凑并且还提供了域不可修改的额外益处。正如下面将要证明的，@Resource注解甚至不需要一个显式的字符串值，在没有提供任何值的情况下，域名将被当作默认值。  
@Resource private DataSource dataSource; // inject the bean named 'dataSource'  
该方式被应用到setter方法的时候，默认名是从相应的属性衍生出来，换句话说，命名为'setDataSource'的方法被用来处理名为'dataSource'的属性。  
private DataSource dataSource; @Resource public void setDataSource(DataSource dataSource) \{ this.dataSource = dataSource; \}  
当@Resource没有显式提供名字的时候，如果根据默认名字找不到对应的Spring管理对象，注入机制会回滚至类型匹配（type-match）。如果刚好只有一个Spring管理对象符合该依赖的类型，那么它会被注入。通过设置CommonAnnotationBeanPostProcessor 的‘fallbackToDefaultTypeMatch’属性为“false”（默认值是“true”）可以禁用这一特性。  
<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"> <property name="fallbackToDefaultTypeMatch" value="false"/> </bean>  
正如上文所提到的，在解析标有@Resource注解的依赖时，Spring支持JNDI-lookup。如若要强制对所有使用@Resource注解的依赖进行JNDI lookup，那也只要将CommonAnnotationBeanPostProcessor的'alwaysUseJndiLookup' 标识设置为true就可以了（默认值是false）。  
<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"> <property name="alwaysUseJndiLookup" value="true"/> </bean>  
另一个选择是，激活指定为‘resource-ref-mappings’的依据全局JNDI名的查找，在@Resource注解内提供‘mappedName’属性。即使目标对象实际上是一个JNDI资源，仍然推荐引入一个Spring管理对象，这样可以提供一个间接层并且因此降低耦合程度。自Spring2.0开始添加命名空间以来，定义一个委托Spring处理JNDI lookup的bean也变得愈发简练：  
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/petclinic"/>  
这个方法的优点在于间接层带来了巨大的部署弹性。比如说，一个单独的系统测试环境应该不再需要JNDI注册。在这种情况下，在系统测试配置中可以提供如下的bean定义：  
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource" p:driverClassName="$\{jdbc.driverClassName\}" p:url="$\{jdbc.url\}" p:username="$\{jdbc.username\}" p:password="$\{jdbc.password\}"/>  
顺便提一下，上面的例子中，实际的JDBC连接属性从一个属性文件（properties file）解析而来，在这个属性文件里，关键字与提供的$\{占位符\}互相对应，这需要注册一个名为PropertyPlaceholderConfigurer的BeanFactoryPostProcessor实现来完成。这是具体化那些属性（通常是针对特定环境的属性）常用的技术，这些属性可能比其他配置修改得更为频繁。  
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="location" value="classpath:jdbc.properties"/> </bean>  
Srping2.5中新加入了‘context’命名空间，这个命名空间让我们能够得到更为简洁的方式来实现属性占位符（property placeholder）的配置：  
<context:property-placeholder location="classpath:jdbc.properties"/>