天天看點

詳解 Spring 3.0 基于 Annotation 的依賴注入實作----注解詳解

使用 @Repository、@Service、@Controller 和 @Component 将類辨別為 Bean

Spring 自 2.0 版本開始,陸續引入了一些注解用于簡化 Spring 的開發。@Repository 注解便屬于最先引入的一批,它用于将資料通路層 (DAO 層 ) 的類辨別為 Spring Bean。具體隻需将該注解标注在 DAO 類上即可。同時,為了讓 Spring 能夠掃描類路徑中的類并識别出 @Repository 注解,需要在 XML 配置檔案中啟用 Bean 的自動掃描功能,這可以通過 <context:component-scan/> 實作。如下所示:

// 首先使用 @Repository 将 DAO 類聲明為 Bean 
 package bookstore.dao; 
 @Repository 
 public class UserDaoImpl implements UserDao{ …… } 

 // 其次,在 XML 配置檔案中啟動 Spring 的自動掃描功能
 <beans … > 
    ……
 <context:component-scan base-package=”bookstore.dao” /> 
……
 </beans>      

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

為什麼 @Repository 隻能标注在 DAO 類上呢?這是因為該注解的作用不隻是将類識别為 Bean,同時它還能将所标注的類中抛出的資料通路異常封裝為 Spring 的資料通路異常類型。 Spring 本身提供了一個豐富的并且是與具體的資料通路技術無關的資料通路異常結構,用于封裝不同的持久層架構抛出的異常,使得異常獨立于底層的架構。

Spring 2.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 ...> 
 <context:component-scan 
    base-package="a.b" name-generator="a.SimpleNameGenerator"/> 
 </beans>      

與通過 XML 配置的 Spring Bean 一樣,通過上述注解辨別的 Bean,其預設作用域是"singleton",為了配合這四個注解,在标注 Bean 的同時能夠指定 Bean 的作用域,Spring 2.5 引入了 @Scope 注解。使用該注解時隻需提供作用域的名稱就行了,如下所示:

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

如果你想提供一個自定義的作用域解析政策而不使用基于注解的方法,隻需實作 ScopeMetadataResolver 接口,确認包含一個預設的沒有參數的構造方法。然後在配置掃描器時提供全限定類名:

<context:component-scan base-package="a.b"
 scope-resolver="footmark.SimpleScopeResolver" />      

回頁首

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

Spring Bean 是受 Spring IoC 容器管理,由容器進行初始化和銷毀的(prototype 類型由容器初始化之後便不受容器管理),通常我們不需要關注容器對 Bean 的初始化和銷毀操作,由 Spring 經過構造函數或者工廠方法建立的 Bean 就是已經初始化完成并立即可用的。然而在某些情況下,可能需要我們手工做一些額外的初始化或者銷毀操作,這通常是針對一些資源的擷取和釋放操作。Spring 1.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>      

Spring 2.5 在保留以上兩種方式的基礎上,提供了對 JSR-250 的支援。JSR-250 規範定義了兩個用于指定聲明周期方法的注解:@PostConstruct 和 @PreDestroy。這兩個注解使用非常簡單,隻需分别将他們标注于初始化之後執行的回調方法或者銷毀之前執行的回調方法上。由于使用了注解,是以需要配置相應的 Bean 後處理器,亦即在 XML 中增加如下一行:

<context:annotation-config />      

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

回頁首

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

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

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

  • none -- 預設不執行依賴檢查。可以在 <beans> 标簽上使用 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 在解析的時候會抛出異常,以提醒開發者對相應屬性進行設定。

回頁首

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

自動裝配是指,Spring 在裝配 Bean 的時候,根據指定的自動裝配規則,将某個 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 的名字作為鍵。

我們可以給 <beans> 增加 default-autowire 屬性,設定預設的自動封裝政策。預設值為"no"。如果使用自動裝配的同時,也指定了 property 或者 constructor-arg 标簽,則顯式指定的值将覆寫自動裝配的值。目前的自動封裝不支援簡單類型,比如基本類型、String、Class,以及它們的數組類型。

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

  • 取消該 Bean 的自動裝配特性,使用顯式的注入。我們可能不希望某個 Bean 被當作其他 Bean 執行自動封裝時的候選對象,我們可以給該 <bean> 增加 autowire-candidate="false"。(autowire-candidate 屬性和 autowire 屬性互相獨立,互不相幹。某個 Bean 可以将 autowire-candidate 設定為 false,同時使用 autowire 特性。) 另外,我們可以設定 <beans> 的 default-autowire-candidates 屬性,可以在該屬性中指定可以用于自動裝配候選 Bean 的比對模式,比如 default-autowire-candidates="*serv,*dao",這表示所有名字以 serv 或者 dao 結尾的 Bean 被列為候選,其他則忽略,相當于其他 Bean 都指定為 autowire-candidate="false",此時可以顯式為 <bean> 指定 autowire-candidate="true"。在 <bean> 上指定的設定要覆寫 <beans> 上指定的設定。
  • 如果在多個類型相同的 Bean 中有首選的 Bean,那麼可以将該 <bean> 的 primary 屬性設定為 "true" ,這樣自動裝配時便優先使用該 Bean 進行裝配。此時不能将 autowire-candidate 設為 false。
  • 如果使用的是 Java 5 以上版本,可以使用注解進行更細粒度的控制。

使用 @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 标注放置在方法聲明上面,但是推薦放置在參數前面 ),舉例如下:

@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 應該是有業務含義的,例如 "domain","persistent" 等,而不應該是類似 "person" 方式。

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

最後,配置檔案中需要指定每一個自定義注解的屬性值。我們可以使用 <meta> 标簽來代替 <qualifier/> 标簽,如果 <meta> 标簽和 <qualifier/> 标簽同時出現,那麼優先使用 <qualifier> 标簽。如果沒有 <qualifier> 标簽,那麼會用 <meta> 提供的鍵值對來封裝 <qualifier> 标簽。示例如下:

<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 等系統類型,那麼則不需要 @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 等價,并且不被忽略。

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

回頁首

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

雖然 2.0 版本釋出以來,Spring 陸續提供了十多個注解,但是提供的這些注解隻是為了在某些情況下簡化 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 容器的唯一配置方式。兩者在一定範圍記憶體在着競争的關系,但是它們在大多數情況下還是互相協作的關系,兩者的結合使得 Spring IoC 容器的配置更簡單,更強大。

之前,我們将配置資訊集中寫在 XML 中,如今使用注解,配置資訊的載體由 XML 檔案轉移到了 Java 類中。我們通常将用于存放配置資訊的類的類名以 “Config” 結尾,比如 AppDaoConfig.java、AppServiceConfig.java 等等。我們需要在用于指定配置資訊的類上加上 @Configuration 注解,以明确指出該類是 Bean 配置的資訊源。并且 Spring 對标注 Configuration 的類有如下要求:

  • 配置類不能是 final 的;
  • 配置類不能是本地化的,亦即不能将配置類定義在其他類的方法内部;
  • 配置類必須有一個無參構造函數。

AnnotationConfigApplicationContext 将配置類中标注了 @Bean 的方法的傳回值識别為 Spring Bean,并注冊到容器中,受 IoC 容器管理。@Bean 的作用等價于 XML 配置中的 <bean/> 标簽。示例如下:

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

Spring 在解析到以上檔案時,将識别出标注 @Bean 的所有方法,執行之,并将方法的傳回值 ( 這裡是 UserDaoImpl 和 BookDaoImpl 對象 ) 注冊到 IoC 容器中。預設情況下,Bean 的名字即為方法名。是以,與以上配置等價的 XML 配置如下:

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

@Bean 具有以下四個屬性:

  • name -- 指定一個或者多個 Bean 的名字。這等價于 XML 配置中 <bean> 的 name 屬性。
  • initMethod -- 容器在初始化完 Bean 之後,會調用該屬性指定的方法。這等價于 XML 配置中 <bean> 的 init-method 屬性。
  • destroyMethod -- 該屬性與 initMethod 功能相似,在容器銷毀 Bean 之前,會調用該屬性指定的方法。這等價于 XML 配置中 <bean> 的 destroy-method 屬性。
  • autowire -- 指定 Bean 屬性的自動裝配政策,取值是 Autowire 類型的三個靜态屬性。Autowire.BY_NAME,Autowire.BY_TYPE,Autowire.NO。與 XML 配置中的 autowire 屬性的取值相比,這裡少了 constructor,這是因為 constructor 在這裡已經沒有意義了。

@Bean 沒有直接提供指定作用域的屬性,可以通過 @Scope 來實作該功能,關于 @Scope 的用法已在上文列舉。

下面講解基于注解的容器初始化。AnnotationConfigApplicationContext 提供了三個構造函數用于初始化容器。

  • AnnotationConfigApplicationContext():該構造函數初始化一個空容器,容器不包含任何 Bean 資訊,需要在稍後通過調用其 register() 方法注冊配置類,并調用 refresh() 方法重新整理容器。
  • AnnotationConfigApplicationContext(Class<?>... annotatedClasses):這是最常用的構造函數,通過将涉及到的配置類傳遞給該構造函數,以實作将相應配置類中的 Bean 自動注冊到容器中。
  • AnnotationConfigApplicationContext(String... basePackages):該構造函數會自動掃描以給定的包及其子包下的所有類,并自動識别所有的 Spring Bean,将其注冊到容器中。它不但識别标注 @Configuration 的配置類并正确解析,而且同樣能識别使用 @Repository、@Service、@Controller、@Component 标注的類。

除了使用上面第三種類型的構造函數讓容器自動掃描 Bean 的配置資訊以外,AnnotationConfigApplicationContext 還提供了 scan() 方法,其功能與上面也類似,該方法主要用在容器初始化之後動态增加 Bean 至容器中。調用了該方法以後,通常需要立即手動調用 refresh() 重新整理容器,以讓變更立即生效。

需要注意的是,AnnotationConfigApplicationContext 在解析配置類時,會将配置類自身注冊為一個 Bean,因為 @Configuration 注解本身定義時被 @Component 标注了。是以可以說,一個 @Configuration 同時也是一個 @Component。大多數情況下,開發者用不到該 Bean,并且在理想情況下,該 Bean 應該是對開發者透明的。@Configuration 的定義如下所示:

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

在一般的項目中,為了結構清晰,通常會根據軟體的子產品或者結構定義多個 XML 配置檔案,然後再定義一個入口的配置檔案,該檔案使用 <import/> 将其他的配置檔案組織起來。最後隻需将該檔案傳給 ClassPathXmlApplicationContext 的構造函數即可。針對基于注解的配置,Spring 也提供了類似的功能,隻需定義一個入口配置類,并在該類上使用 @Import 注解引入其他的配置類即可,最後隻需要将該入口類傳遞給 AnnotationConfigApplicationContext。具體示例如下:

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

回頁首

混合使用 XML 與注解進行 Bean 的配置

設計 @Configuration 和 @Bean 的初衷,并不是為了完全取代 XML,而是為了在 XML 之外多一種可行的選擇。由于 Spring 自釋出以來,Spring 開發小組便不斷簡化 XML 配置,使得 XML 配置方式已經非常成熟,加上 Spring 2.0 以後出現了一系列命名空間的支援,使得 XML 配置方式成為了使用簡單、功能強大的 Bean 定義方式。而且,XML 配置的一些進階功能目前還沒有相關注解能夠直接支援。是以,在目前的多數項目中,要麼使用純粹的 XML 配置方式進行 Bean 的配置,要麼使用以注解為主,XML 為輔的配置方式進行 Bean 的配置。

之是以會出現兩者共存的情況,主要歸結為三個原因:其一,目前絕大多數采用 Spring 進行開發的項目,幾乎都是基于 XML 配置方式的,Spring 在引入注解的同時,必須保證注解能夠與 XML 和諧共存,這是前提;其二,由于注解引入較晚,是以功能也沒有發展多年的 XML 強大,是以,對于複雜的配置,注解還很難獨當一面,在一段時間内仍然需要 XML 的配合才能解決問題。除此之外,Spring 的 Bean 的配置方式與 Spring 核心子產品之間是解耦的,是以,改變配置方式對 Spring 的架構自身是透明的。Spring 可以通過使用 Bean 後處理器 (BeanPostProcessor) 非常友善的增加對于注解的支援。這在技術實作上非常容易的事情。

要使用混合配置方式,首先需要判斷以哪一種配置方式為主。對這個問題的不同回答将會直接影響到實作的方式。然而大可不必為此傷腦筋,因為不論是以 XML 為主,還是以注解為主,配置方式都是簡單而且容易了解的。這裡不存在錯誤的決定,因為僅僅是表現方式不一樣。我們首先假設以 XML 配置為主的情況。

對于已經存在的大型項目,可能初期是以 XML 進行 Bean 配置的,後續逐漸加入了注解的支援,這時我們隻需在 XML 配置檔案中将被 @Configuration 标注的類定義為普通的 <bean>,同時注冊處理注解的 Bean 後處理器即可。示例如下:

// 假設存在如下的 @Configuration 類:
 package bookstore.config; 
 import bookstore.dao.*; 
 @Configuration 
 public class MyConfig{ 
 @Bean 
    public UserDao userDao(){ 
        return new UserDaoImpl(); 
    } 
 } 
此時,隻需在 XML 中作如下聲明即可:
 <beans … > 
    ……
    <context:annotation-config /> 
    <bean class=”demo.config.MyConfig”/> 
 </beans>      

由于啟用了針對注解的 Bean 後處理器,是以在 ApplicationContext 解析到 MyConfig 類時,會發現該類标注了 @Configuration 注解,随後便會處理該類中标注 @Bean 的方法,将這些方法的傳回值注冊為容器總的 Bean。

對于以上的方式,如果存在多個标注了 @Configuration 的類,則需要在 XML 檔案中逐一列出。另一種方式是使用前面提到的自動掃描功能,配置如下:

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

如此,Spring 将掃描所有 demo.config 包及其子包中的類,識别所有标記了 @Component、@Controller、@Service、@Repository 注解的類,由于 @Configuration 注解本身也用 @Component 标注了,Spring 将能夠識别出 @Configuration 标注類并正确解析之。

對于以注解為中心的配置方式,隻需使用 @ImportResource 注解引入存在的 XML 即可,如下所示:

@Configuration 
 @ImportResource(“classpath:/bookstore/config/spring-beans.xml”) 
 public class MyConfig{ 
……
 } 
 // 容器的初始化過程和純粹的以配置為中心的方式一緻:
 AnnotationConfigApplicationContext ctx = 
              new AnnotationConfigApplicationContext(MyConfig.class); 
……      

結束語

從 2.0 版本開始,Spring 的每一次更新都會提供更多新的注解供開發者使用。這滿足了注解愛好者的胃口。但是正如前面所說,Spring 提供更多的注解并不是為了有朝一日取代 XML 配置方式,而是為了給開發者多一種選擇。兩種聲明 Bean 的方式各有特色,XML 方式更加靈活,并且發展的相對成熟,這種配置方式為大多數 Spring 開發者熟悉;注解方式使用起來非常簡潔,但是尚處于發展階段。我們很難說兩種配置方式孰優孰劣,但是如果能夠靈活搭配兩種方式,一定能夠進一步提升開發效率。

轉自:http://www.ibm.com/developerworks/cn/opensource/os-cn-spring-iocannt/