Spring 多種方式初始化
1. 前言
通過之前的學習,我們可以熟練掌握 Spring 容器初始化的方法。常用的方法:一種是純 xml 文件的方式,第二種是使用群體最多的一種,就是 xml 文件搭配類上面的注解,來進行初始化容器。
我們今天講解一種全新的方法,也是目前最為流行的一種方法。是基于 JavaConfig 的方式來實現。通俗地說也叫基于注解的方式。
疑問導出:
我們學完了那么多種 Spring 的使用,其實完全可以勝任開發的需求,還有必要學習一種新的初始化方式嗎? 它又有什么優點呢?
伴隨疑問:我們開始新的小節學習。
2. 注解介紹
2.1 注解列舉
- @Bean
- @Configuration
- @ComponentScan
- @Component @Service @Controller @Repository
上述注解是我們在案例中需要使用到的。當然對于我們來講,其實最后面的幾個注解已經是熟客了,也就不多介紹。所以我把他們放到了一起。
上面的三個我們是沒有用過的,所以下面我分別對三個注解做個解釋說明。
2.2 注解作用闡述
1.@Bean 注解的解釋:
見名知意,此注解作用于方法上,表示方法返回的實例初始化到由 Spring 管理的容器中。其實對現在的我們而言,非常好理解。因為我們知道 Spring 的 IoC 其實就是控制反轉,實例化 bean 實例,管理 bean 實例。
相當于使用 xml 文件方式的 <bean> 標簽,一般來說,此注解出現在被 @Configuration
注釋的類中。
那么…@Configuration 注解的作用又是什么呢?
2.@Configuration 注解的解釋:
其實看此注解的名稱,也能大致猜到它的作用。沒錯,它的作用就是配置,也就是相當于我們之前編寫過很多次的 Spring 配置文件 ——Applicationcontext.xml
。
之前寫過的案例中,Spring 容器的初始化必須加載這個配置文件,而在配置文件中,就包含了很多的 標簽,大家沒忘記吧?不要提了… 不要關了電腦就忘記之前寫過的代碼。
那么我們上面說 @Bean
標簽,一般出現在被此注解注釋的類中,就是這個原因。
3.@ComponentScan 注解的解釋:
根據上面兩個注解的推斷,我們能猜出它的作用就是組件掃描。相當于之前我們在 Spring 的配置文件中用過的標簽 context:component-scan,
現在講述使用 JavaConfig 是基于注解的方式,當然也避免不了組件的掃描。此注解也是配置類的組成部分。
搭建項目最基本的三個注解給大家介紹過了,下面我們就進入正題。
3. 工程實例
工程步驟:
- 創建 maven 工程
- 導入依賴
- 編寫配置類
- 測試代碼
步驟解釋:
第一步,第二步省略,實在演示太多次了。誰不會拖出去槍斃十分鐘… 剩下的咱們繼續。
配置類:
在 src 下的 com.wyan.config
目錄之下創建配置類 SpringConfig,代碼與目錄結構如下:
代碼解釋:
SpringConfig 的類上面的注解,表示當前的類是個配置類,容器中的 bean 實例都從這個配置類中來。
@Bean
注解所在的方法會返回 UserServiceImpl 的實例,而且被 Spring 的容器管理。
測試類:
代碼解釋:
- 16 行的代碼,我們看到一個新的類叫做
AnnotationConfigApplicationContext
,此類是注解配置應用容器。 - 17 行代碼,通過調用方法 register () 將配置類 SpringConfig 作為參數傳入,容器就成功加載了配置類。
- 18 行刷新方法調用大家應該不陌生吧,在源碼解釋的小節,就看到它內部就是初始化容器的詳細步驟。
測試結果:
上面可以看到,servcie 的實例確實從容器中獲取得到,那么說明,我們基于 JavaConfig 的配置方式已經實現完成。但可能大家會有一點疑問:
配置類中的方法是返回 bean 對象的實例,放入容器。那么一個方法返回一個 bean ,如果我們的項目中存在非常多的類,難道需要創建很多個方法嗎?
下面使用最后一個注解,也就是 @ComponentScan
的使用。
更改配置類:
代碼解釋:
- 在類上面加入注解
@ComponentScan
,而注解中的值,就是需要被掃描的組件類所在目錄; - 因為通過掃描加載組件,所以之前創建 bean 返回實例的方法不需要;
- 掃描的 servcie 目錄下的類上一定需要搭配
@Service
@Controller
@Repository
@Component
。
測試結果:
4. 小結
本節,主要講解 Spring 容器的基于 JavaConfig 的實現方式。核心思想是借助于注解加載配置,加載 bean。與其他方式相比各有利弊,大家不要執著于形式,根據自己的開發習慣,公司規范來選擇就可以。