如此，我們就不再需要在 XML 中顯式使用 進行 Bean 的配置。Spring 在容器初始化時將自動掃描 base-package 指定的包及其子包下的所有 class 文件，所有標注了 @Repository 的類都將被注冊為 Spring Bean。

為什么 @Repository 只能標注在 DAO 類上呢?這是因為該注解的作用不只是將類識別為 Bean，同時它還能將所標注的類中拋出的數據訪問異常封裝為 Spring 的數據訪問異常類型。 Spring 本身提供了一個豐富的并且是與具體的數據訪問技術無關的數據訪問異常結構，用于封裝不同的持久層框架拋出的異常，使得異常獨立于底層的框架。

Spring 2.5 在 @Repository 的基礎上增加了功能類似的額外三個注解：@Component、@Service、@Constroller，它們分別用于軟件系統(tǒng)的不同層次：

♦ @Component 是一個泛化的概念，僅僅表示一個組件 (Bean) ，可以作用在任何層次。

♦ @Service 通常作用在業(yè)務層，但是目前該功能與 @Component 相同。

♦ @Constroller 通常作用在控制層，但是目前該功能與 @Component 相同。

通過在類上使用 @Repository、@Component、@Service 和 @Constroller 注解，Spring 會自動創(chuàng)建相應的 BeanDefinition 對象，并注冊到 ApplicationContext 中。這些類就成了 Spring 受管組件。這三個注解除了作用于不同軟件層次的類，其使用方式與 @Repository 是完全相同的。

另外，除了上面的四個注解外，用戶可以創(chuàng)建自定義的注解，然后在注解上標注 @Component，那么，該自定義注解便具有了與所 @Component 相同的功能。不過這個功能并不常用。

當一個 Bean 被自動檢測到時，會根據那個掃描器的 BeanNameGenerator 策略生成它的 bean 名稱。默認情況下，對于包含 name 屬性的 @Component、@Repository、 @Service 和 @Controller，會把 name 取值作為 Bean 的名字。如果這個注解不包含 name 值或是其他被自定義過濾器發(fā)現的組件，默認 Bean 名稱會是小寫開頭的非限定類名。如果你不想使用默認 bean 命名策略，可以提供一個自定義的命名策略。首先實現 BeanNameGenerator 接口，確認包含了一個默認的無參數構造方法。然后在配置掃描器時提供一個全限定類名，如下所示：

<beans ...>   
<context:component-scan   
    base-package="a.b" name-generator="a.SimpleNameGenerator"/>   
beans>  

@Scope("prototype")   
@Repository   
public class Demo { … }  

package="a.b"     
scope-resolver="footmark.SimpleScopeResolver" />   

使用 @PostConstruct 和 @PreDestroy 指定生命周期回調方法

Spring Bean 是受 Spring IoC 容器管理，由容器進行初始化和銷毀的(prototype 類型由容器初始化之后便不受容器管理)，通常我們不需要關注容器對 Bean 的初始化和銷毀操作，由 Spring 經過構造函數或者工廠方法創(chuàng)建的 Bean 就是已經初始化完成并立即可用的。然而在某些情況下，可能需要我們手工做一些額外的初始化或者銷毀操作，這通常是針對一些資源的獲取和釋放操作。Spring 1.x 為此提供了兩種方式供用戶指定執(zhí)行生命周期回調的方法。

第一種方式是實現 Spring 提供的兩個接口：InitializingBean 和 DisposableBean。如果希望在 Bean 初始化完成之后執(zhí)行一些自定義操作，則可以讓 Bean 實現 InitializingBean 接口，該接口包含一個 afterPropertiesSet() 方法，容器在為該 Bean 設置了屬性之后，將自動調用該方法;如果 Bean 實現了 DisposableBean 接口，則容器在銷毀該 Bean 之前，將調用該接口的 destroy() 方法。這種方式的缺點是，讓 Bean 類實現 Spring 提供的接口，增加了代碼與 Spring 框架的耦合度，因此不推薦使用。

第二種方式是在 XML 文件中使用 的 init-method 和 destroy-method 屬性指定初始化之后和銷毀之前的回調方法，代碼無需實現任何接口。這兩個屬性的取值是相應 Bean 類中的初始化和銷毀方法，方法名任意，但是方法不能有參數。示例如下：

<bean id=”userService”   
class=”bookstore.service.UserService”   
init-method=”init” destroy-method=”destroy”>   
    …   
bean>  

Spring 2.5 在保留以上兩種方式的基礎上，提供了對 JSR-250 的支持。JSR-250 規(guī)范定義了兩個用于指定聲明周期方法的注解：@PostConstruct 和 @PreDestroy。這兩個注解使用非常簡單，只需分別將他們標注于初始化之后執(zhí)行的回調方法或者銷毀之前執(zhí)行的回調方法上。由于使用了注解，因此需要配置相應的 Bean 后處理器，亦即在 XML 中增加如下一行：

<context:annotation-config />  

比較上述三種指定生命周期回調方法的方式，第一種是不建議使用的，不但其用法不如后兩種方式靈活，而且無形中增加了代碼與框架的耦合度。后面兩種方式開發(fā)者可以根據使用習慣選擇其中一種，但是最好不要混合使用，以免增加維護的難度。

使用 @Required 進行 Bean 的依賴檢查

依賴檢查的作用是，判斷給定 Bean 的相應 Setter 方法是否都在實例化的時候被調用了。而不是判斷字段是否已經存在值了。Spring 進行依賴檢查時，只會判斷屬性是否使用了 Setter 注入。如果某個屬性沒有使用 Setter 注入，即使是通過構造函數已經為該屬性注入了值，Spring 仍然認為它沒有執(zhí)行注入，從而拋出異常。另外，Spring 只管是否通過 Setter 執(zhí)行了注入，而對注入的值卻沒有任何要求，即使注入的 ，Spring 也認為是執(zhí)行了依賴注入。

標簽提供了 dependency-check 屬性用于進行依賴檢查。該屬性的取值包括以下幾種：

♦ none -- 默認不執(zhí)行依賴檢查。可以在 標簽上使用 default-dependency-check 屬性改變默認值。

♦ simple -- 對原始基本類型和集合類型進行檢查。

♦ objects -- 對復雜類型進行檢查(除了 simple 所檢查類型之外的其他類型)。

♦ all -- 對所有類型進行檢查。

舊版本使用 dependency-check 在配置文件中設置，缺點是粒度較粗。使用 Spring2.0 提供的 @Required 注解，提供了更細粒度的控制。@Required 注解只能標注在 Setter 方法之上。因為依賴注入的本質是檢查 Setter 方法是否被調用了，而不是真的去檢查屬性是否賦值了以及賦了什么樣的值。如果將該注解標注在非 setXxxx() 類型的方法則被忽略。

為了讓 Spring 能夠處理該注解，需要激活相應的 Bean 后處理器。要激活該后處理器，只需在 XML 中增加如下一行即可。

<context:annotation-config/>  

當某個被標注了 @Required 的 Setter 方法沒有被調用，則 Spring 在解析的時候會拋出異常，以提醒開發(fā)者對相應屬性進行設置。

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

自動裝配是指，Spring 在裝配 Bean 的時候，根據指定的自動裝配規(guī)則，將某個 Bean 所需要引用類型的 Bean 注入進來。 元素提供了一個指定自動裝配類型的 autowire 屬性，該屬性有如下選項：

♦ no -- 顯式指定不使用自動裝配。

♦ byName -- 如果存在一個和當前屬性名字一致的 Bean，則使用該 Bean 進行注入。如果名稱匹配但是類型不匹配，則拋出異常。如果沒有匹配的類型，則什么也不做。

♦ byType -- 如果存在一個和當前屬性類型一致的 Bean ( 相同類型或者子類型 )，則使用該 Bean 進行注入。byType 能夠識別工廠方法，即能夠識別 factory-method 的返回類型。如果存在多個類型一致的 Bean，則拋出異常。如果沒有匹配的類型，則什么也不做。

♦ constructor -- 與 byType 類似，只不過它是針對構造函數注入而言的。如果當前沒有與構造函數的參數類型匹配的 Bean，則拋出異常。使用該種裝配模式時，優(yōu)先匹配參數最多的構造函數。

♦ autodetect -- 根據 Bean 的自省機制決定采用 byType 還是 constructor 進行自動裝配。如果 Bean 提供了默認的構造函數，則采用 byType;否則采用 constructor 進行自動裝配。

當使用 byType 或者 constructor 類型的自動裝配的時候，自動裝配也支持引用類型的數組或者使用了泛型的集合，這樣，Spring 就會檢查容器中所有類型匹配的 Bean，組成集合或者數組后執(zhí)行注入。對于使用了泛型的 Map 類型，如果鍵是 String 類型，則 Spring 也會自動執(zhí)行裝配，將所有類型匹配的 Bean 作為值，Bean 的名字作為鍵。

我們可以給 增加 default-autowire 屬性，設置默認的自動封裝策略。默認值為"no"。如果使用自動裝配的同時，也指定了 property 或者 constructor-arg 標簽，則顯式指定的值將覆蓋自動裝配的值。目前的自動封裝不支持簡單類型，比如基本類型、String、Class，以及它們的數組類型。

在按類型匹配的時候 ( 可能是 byType、constructor、autodetect)，同一個類型可能存在多個 Bean，如果被注入的屬性是數組、集合或者 Map，這可能沒有問題，但是如果只是簡單的引用類型，則會拋出異常。解決方法有如下幾種：

♦ 取消該 Bean 的自動裝配特性，使用顯式的注入。我們可能不希望某個 Bean 被當作其他 Bean 執(zhí)行自動封裝時的候選對象，我們可以給該 增加 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="false"，此時可以顯式為 指定 autowire-candidate="true"。在 上指定的設置要覆蓋 上指定的設置。

♦ 如果在多個類型相同的 Bean 中有首選的 Bean，那么可以將該 的 primary 屬性設置為 "true" ，這樣自動裝配時便優(yōu)先使用該 Bean 進行裝配。此時不能將 autowire-candidate 設為 false。

♦ 如果使用的是 Java 5 以上版本，可以使用注解進行更細粒度的控制。

使用 @Autowired 和 @Qualifier 注解執(zhí)行自動裝配

使用 @Autowired 注解進行裝配，只能是根據類型進行匹配。@Autowired 注解可以用于 Setter 方法、構造函數、字段，甚至普通方法，前提是方法必須有至少一個參數。@Autowired 可以用于數組和使用泛型的集合類型。然后 Spring 會將容器中所有類型符合的 Bean 注入進來。@Autowired 標注作用于 Map 類型時，如果 Map 的 key 為 String 類型，則 Spring 會將容器中所有類型符合 Map 的 value 對應的類型的 Bean 增加進來，用 Bean 的 id 或 name 作為 Map 的 key。

@Autowired 標注作用于普通方法時，會產生一個副作用，就是在容器初始化該 Bean 實例的時候就會調用該方法。當然，前提是執(zhí)行了自動裝配，對于不滿足裝配條件的情況，該方法也不會被執(zhí)行。

當標注了 @Autowired 后，自動注入不能滿足，則會拋出異常。我們可以給 @Autowired 標注增加一個 required=false 屬性，以改變這個行為。另外，每一個類中只能有一個構造函數的 @Autowired.required() 屬性為 true。否則就出問題了。如果用 @Autowired 同時標注了多個構造函數，那么，Spring 將采用貪心算法匹配構造函數 ( 構造函數最長 )。

@Autowired 還有一個作用就是，如果將其標注在 BeanFactory 類型、ApplicationContext 類型、ResourceLoader 類型、ApplicationEventPublisher 類型、MessageSource 類型上，那么 Spring 會自動注入這些實現類的實例，不需要額外的操作。

當容器中存在多個 Bean 的類型與需要注入的相同時，注入將不能執(zhí)行，我們可以給 @Autowired 增加一個候選值，做法是在 @Autowired 后面增加一個 @Qualifier 標注，提供一個 String 類型的值作為候選的 Bean 的名字。舉例如下：

@Autowired(required=false)   
@Qualifier("ppp")   
public void setPerson(person p){}   

@Qualifier 甚至可以作用于方法的參數 ( 對于方法只有一個參數的情況，我們可以將 @Qualifer 標注放置在方法聲明上面，但是推薦放置在參數前面 )，舉例如下：

@Autowired(required=false)   
public void sayHello(@Qualifier("ppp")Person p,String name){}  

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

<bean id="person" class="footmark.spring.Person">   
    <qualifier value="ppp"/>   
bean>  

如果沒有明確指定 Bean 的 qualifier 名字，那么默認名字就是 Bean 的名字。通常，qualifier 應該是有業(yè)務含義的，例如 "domain"，"persistent" 等，而不應該是類似 "person" 方式。

我們還可以將 @Qualifier 標注在集合類型上，那么所有 qualifier 名字與指定值相同的 Bean 都將被注入進來。

最后，配置文件中需要指定每一個自定義注解的屬性值。我們可以使用 標簽來代替 標簽，如果 標簽和 標簽同時出現，那么優(yōu)先使用 標簽。如果沒有 標簽，那么會用 提供的鍵值對來封裝 標簽。示例如下：

<bean class="footmark.HelloWorld">   
<qualifier type="MovieQualifier">   
<attribute key="format" value="VHS"/>   
<attribute key="genre" value="Comedy"/>   
qualifier>   
bean>   
<bean class="footmark.HelloWorld">   
<meta key="format" value="DVD"/>   
<meta key="genre" value="Action"/>   
bean>   

@Autowired 注解對應的后處理注冊與前面相似，只需在配置文件中增加如下一行即可：

<context:annotation-config/>   

如果 @Autowired 注入的是 BeanFactory、ApplicationContext、ResourceLoader 等系統(tǒng)類型，那么則不需要 @Qualifier，此時即使提供了 @Qualifier 注解，也將會被忽略;而對于自定義類型的自動裝配，如果使用了 @Qualifier 注解并且沒有名字與之匹配的 Bean，則自動裝配匹配失敗。

#p#

使用 JSR-250 中的 @Resource 和 @Qualifier 注解

如果希望根據 name 執(zhí)行自動裝配，那么應該使用 JSR-250 提供的 @Resource 注解，而不應該使用 @Autowired 與 @Qualifier 的組合。

@Resource 使用 byName 的方式執(zhí)行自動封裝。@Resource 標注可以作用于帶一個參數的 Setter 方法、字段，以及帶一個參數的普通方法上。@Resource 注解有一個 name 屬性，用于指定 Bean 在配置文件中對應的名字。如果沒有指定 name 屬性，那么默認值就是字段或者屬性的名字。@Resource 和 @Qualifier 的配合雖然仍然成立，但是 @Qualifier 對于 @Resource 而言，幾乎與 name 屬性等效。

如果 @Resource 沒有指定 name 屬性，那么使用 byName 匹配失敗后，會退而使用 byType 繼續(xù)匹配，如果再失敗，則拋出異常。在沒有為 @Resource 注解顯式指定 name 屬性的前提下，如果將其標注在 BeanFactory 類型、ApplicationContext 類型、ResourceLoader 類型、ApplicationEventPublisher 類型、MessageSource 類型上，那么 Spring 會自動注入這些實現類的實例，不需要額外的操作。此時 name 屬性不需要指定 ( 或者指定為"")，否則注入失敗;如果使用了 @Qualifier，則該注解將被忽略。而對于用戶自定義類型的注入，@Qualifier 和 name 等價，并且不被忽略。

的 primary 和 autowire-candidate 屬性對 @Resource、@Autowired 仍然有效。

使用 @Configuration 和 @Bean 進行 Bean 的聲明

雖然 2.0 版本發(fā)布以來，Spring 陸續(xù)提供了十多個注解，但是提供的這些注解只是為了在某些情況下簡化 XML 的配置，并非要取代 XML 配置方式。這一點可以從 Spring IoC 容器的初始化類可以看出：ApplicationContext 接口的最常用的實現類是 ClassPathXmlApplicationContext 和 FileSystemXmlApplicationContext，以及面向 Portlet 的 XmlPortletApplicationContext 和面向 web 的 XmlWebApplicationContext，它們都是面向 XML 的。Spring 3.0 新增了另外兩個實現類：AnnotationConfigApplicationContext 和 AnnotationConfigWebApplicationContext。從名字便可以看出，它們是為注解而生，直接依賴于注解作為容器配置信息來源的 IoC 容器初始化類。由于 AnnotationConfigWebApplicationContext 是 AnnotationConfigApplicationContext 的 web 版本，其用法與后者相比幾乎沒有什么差別，因此本文將以 AnnotationConfigApplicationContext 為例進行講解。

AnnotationConfigApplicationContext 搭配上 @Configuration 和 @Bean 注解，自此，XML 配置方式不再是 Spring IoC 容器的唯一配置方式。兩者在一定范圍內存在著競爭的關系，但是它們在大多數情況下還是相互協(xié)作的關系，兩者的結合使得 Spring IoC 容器的配置更簡單，更強大。

之前，我們將配置信息集中寫在 XML 中，如今使用注解，配置信息的載體由 XML 文件轉移到了 Java 類中。我們通常將用于存放配置信息的類的類名以 “Config” 結尾，比如 AppDaoConfig.java、AppServiceConfig.java 等等。我們需要在用于指定配置信息的類上加上 @Configuration 注解，以明確指出該類是 Bean 配置的信息源。并且 Spring 對標注 Configuration 的類有如下要求：

♦ 配置類不能是 final 的;

♦ 配置類不能是本地化的，亦即不能將配置類定義在其他類的方法內部;

♦ 配置類必須有一個無參構造函數。

AnnotationConfigApplicationContext 將配置類中標注了 @Bean 的方法的返回值識別為 Spring Bean，并注冊到容器中，受 IoC 容器管理。@Bean 的作用等價于 XML 配置中的 標簽。示例如下：

@Configuration   
public class BookStoreDaoConfig{   
    @Bean   
    public UserDao userDao(){ return new UserDaoImpl();}   
    @Bean   
    public BookDao bookDao(){return new BookDaoImpl();}   
}   

Spring 在解析到以上文件時，將識別出標注 @Bean 的所有方法，執(zhí)行之，并將方法的返回值 ( 這里是 UserDaoImpl 和 BookDaoImpl 對象 ) 注冊到 IoC 容器中。默認情況下，Bean 的名字即為方法名。因此，與以上配置等價的 XML 配置如下：

<bean id=”userDao” class=”bookstore.dao.UserDaoImpl”/>    
 <bean id=”bookDao” class=”bookstore.dao.BookDaoImpl”/>       

@Target({ElementType.TYPE})   
@Retention(RetentionPolicy.RUNTIME)   
@Documented   
@Component   
public @interface Configuration {   
String value() default "";   
}   

@Configuration   
@Import({BookStoreServiceConfig.class,BookStoreDaoConfig.class})   
public class BookStoreConfig{ … }  

package bookstore.config;   
import bookstore.dao.*;   
@Configuration   
public class MyConfig{   
@Bean   
    public UserDao userDao(){   
        return new UserDaoImpl();   
    }   
}  

<beans … >   
    ……   
    <context:annotation-config />   
    <bean class=”demo.config.MyConfig”/>   
beans>  

<context:component-scan base-package=”bookstore.config” />  

@Configuration   
@ImportResource(“classpath:/bookstore/config/spring-beans.xml”)   
public class MyConfig{   
……   
}   

AnnotationConfigApplicationContext ctx =   
              new AnnotationConfigApplicationContext(MyConfig.class);   
……