在以前通常情況下一個簡單的專案一般由兩個及兩個以上的類構成,大多數的類集資料和資料的處理方法於一體,類之間通過依賴彼此的資料和方法實現業務邏輯,這個獲取依賴的過程是自己實現的,導致程式碼高度耦合以及難以測試。
所以出現了DI (依賴注入)、IoC (控制反轉)
這些將物件的依賴關係轉交給平臺或容器進行管理的設計模式,而在 Spring 核心中 IoC 容器就是這種模式的實現。通過將物件的依賴控制交給 IoC 容器從而有效降低程式碼的耦合度,提高程式碼的可測試性。
IoC 容器需要解決的核心問題是如何將物件的控制權從物件轉交給平臺或框架中。
IoC 核心思想是關於一個物件如何獲取它所依賴的物件參照。
這次除了對 IoC 的簡單回顧,還有對 Spring 框架實現的 IoC 容器進行設計和實現上的分析,深入瞭解一下 Spring IoC 獨特的特點。
BeanFactory 介面系列:只實現了容器的基本功能。
ApplicationContext 應用上下文系列:在簡單容器的基礎上增加了許多面向框架的特性,同時對不同的應用場景進行了適配。
下面對其兩者進行逐一分析。
基本概念:BeanFactory 介面定義了一個 IoC 容器所應該具備的最基本服務,同時也是我們使用 IoC 容器遵守的最底層和最基本的程式設計規範。
同時有許多的類實現了 BeanFactory 這個基本介面,並在其基礎上進行了適當的擴充套件形成了具體的 IoC 容器,以針對不同的場景供使用者選擇,其中 ApplicationContext 也是在其基礎上構造的。
BeanFactory 介面的原始碼:
這些規範,體現了 IoC 容器最基本的特性。
其中主要的方法就是 getBean()
方法,還有一些其他的檢索方法,是最為基本的容器入口。
可以通過分析一個基本的 IoC 容器—— XmlBeanFactory
實現,來嘗試理解簡單 IoC 容器的設計原理。
XmlBeanFactory 使用了 DefaultListableBeanFactory 作為基礎類別,兩者作為基本的 IoC 容器,通過觀察 XBF 這個類名,可以猜到大概是通過 XML 檔案來解析 BeanDefinition,並初始化 IoC 容器(事實也是如此)。
可以看到有一個常數,XmlBeanDefinitionReader
這個類是用來解析處理以 XML 形式定義的 BeanDefinition,是 Reader
物件,但是並不是它來獲取 XML 資源,XML 資源是交由另一個物件(Resource)來獲取並抽象的。Resource
是 Spring 用來封裝 I/O 操作的類(稱為定位 BeanDefinition 資源),例如 ClassPathResource
這個類可以指定獲取到具體的資源,並且將 Resuorce 交由 XBF 的建構函式,這樣 IoC 容器就可以方便的定位到需要的 BeanDefinition 資訊對 Bean 完成容器的初始化和 DI 過程。
可能思路還不是很清晰,接下來就簡單解釋一下一些類:
BeanDefinition:
這個類是 Spring 為了方便 IoC 容器管理 POJO (Bean) 物件而對其進一步抽象的資料結構,根據資源所定義的資訊來建立具體的 Bean 物件。
假設我們通過 XML 的形式來讓 IoC 容器幫我們管理 Bean 物件,其實我們在 XML 中定義的是 BeanDefinition,我們通過 <bean/>
標籤來建立 Bean,實際上是在描述一個 BeanDefinition,而當 IoC 容器通過 Reader 定位到 需要的 BeanDefinitieon,則是根據 Reader 解析好的 BeanDefinition 資訊來建立我們描述好的 Bean 物件,並進行管理。
BeanDefinitionReader:
讀取 Spring 組態檔中的內容,並將其轉換為 IoC 容器的內部資料結構:BeanDefinition。
在 XBF 中 XBDR 就是 BDR 的一個具體實現,Spring 的設定內容是 XML,所以根據 XML 的形式來轉換 BeanDefinition。
Resource:
Spring 統一對不同來源的資源進行底層抽象,方便統一管理不同的資源。
通過簡單的觀察繼承關係和部分原始碼,大概分析是 Spring 對不同來源的資源統一進行底層資源封裝或抽象。
再通過不同的實現類對具體的資源面向使用者提高具體的服務介面。
通過解釋或者百度幾個關鍵類,我們應該能理解 IoC 容器初始化的簡單過程。
觀察 XBF 的原始碼可以發現除了使用 XBDR 物件進行資源的解析和載入,並沒有看到關於 IoC 容器的初始化過程,看到 super(parentBeanFactory)
這句程式碼呼叫了父類別 —— DefaultListableBeanFactory
的構造方法,從而完成了 IoC 容器的構建。那麼我們初步可以分析出 DefaultListableBeanFactory
應該是 XBF IoC 容器建立的重要物件。實際上它也是個基本 IoC 容器。
直到這裡我們就簡單分析出了 XBF IoC 容器的建立過程。
通過 reader 解析好的 Bean 資訊載入到 BeanFactory (IoC 容器)中。
對於開發人員來說,例如開發一個 Web 伺服器端,如果要開發人員手動控制 Bean 的設定和容器的建立過程,無疑是非常痛苦的,所以 Spring 幫我們定義了許多已經實現好的容器,並且這些容器面向的需求也不一樣,相對於已經實現的簡單 BeanFactory 容器,不能很大程度上滿足開發人員的需求,所以 ApplicationContext 無疑是更好的選擇。
之前介紹了 ApplicationContext 是在基本 IoC 容器上,進行了更大程度的擴充套件,讓 IoC 容器面向框架,提供更多的服務,方便開發人員的使用,更加專注於業務邏輯的實現。同時也是對 IoC 容器一次全面的更新和擴充套件。
AC 擴充套件了一些介面,在基礎 IoC 容器上新增了附加功能,這些額外的功能為 AC 提供了 BeanFactory 不具備的特性:
支援不同的資訊源:擴充套件了 MessageSource
介面,支援國際化,為開發多語言版本的應用提供服務。
存取資源:主要體現在對 ResourceLoader
和 Resource
的支援上,讓我們可以獲從不同的地方獲取 Bean 資源,主要是可以在不同的 I/O 途徑獲取 Bean 定義資訊。這裡的指的是具體的 ApplicationContext 容器,一般來說都是繼承了 DefaultResourceLoader 的子類,因為 DefaultResourceLoader 是 AbstractApplicationContext 的基礎類別。
支援應用事件
繼承了介面 ApplicationEventPublisher,從而在上下文中引入了事件機制,這些事件結合 Bean 的生命週期對 Bean 管理提供了便利。
提供其他附加服務
這些其他的附加服務,使得基本的 IoC 的功能更加豐富,使它的使用是一種面向框架 的使用風格。
設計原理:
以常用的 FileSystemXmlApplicationContext
的實現為例說明 ApplicationContext 容器的設計原理。
通過觀察 FSXAC 的原始碼,AC 容器的主要功能已經在 FSXAC 的基礎類別 AbstractXmlApplicationContext
中實現了,所以 FSXAC 只要實現與自身設計相關的兩個功能。
功能一:如果直接使用 FSXAC,對於範例化這個應用上下文的支援,同時啟動 IoC 容器的 refresh()
過程。
refresh()
過程牽涉到 IoC 容器啟動的一系列複雜操作,對於不同的容器,這些操作都是類似的,因此在基礎類別(AbstractApplicationContext
)中對其統一封裝。
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent) throws BeansException {
super(parent);
this.setConfigLocations(configLocations);
if (refresh) {
this.refresh();
}
}
功能二: 如何從檔案系統中載入 XML 的 Bean 定義資源有關。
簡單來說就是如何在檔案系統中讀取以 XML 形式存在的 BeanDefinition 做準備(並不是直接解析),因為不同的 AC 實現對應著不同的讀取 BeanDefinition 的方式。
protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
上面是這個功能的實現,可以看到,呼叫這個方法可以得到 Resource
資源定位——FileSystemResource
。
本次學習了 IoC 容器的一些介紹和概念,抓住了在 Spring 中 IoC 容器的兩大實現方式:BeanFactory 和 ApplicationContext.
藉助常用或典型的實現類:XmlBeanFactory
和 FileSystemApplicationContext
。
通過簡單分析兩者的實現和設計區別,來嘗試理解兩者本質或定義上的區別,同時我們也在兩者的實現和設計中,學到了 Spring IoC 容器中基礎的組成部分:
這些與 IoC 容器密切相關。
在平時的 Spring 學習和使用中,我們大部分都僅限於使用,有時候專案報錯,即使百度,也會出現不能快速定位或者解決了但是又沒完全解決(不理解)的情況。
除了收集我們的日常 BUG 外,我們還需要對其淺層原理進行理解。我想這應該是逃離「碼農」的一小步。
努力地靠近自己理解的正軌。