設計模式之spring分析 mysql oracle html5

標籤：

設計模式之spring分析

         Spring已經在java的世界裡橫行很多年了，但是閱讀起來並不那麼容易。特別是介面概念的廣泛使用，更增加了分析的難度，本文從設計模式的角度來對其進行分析，會忽略實現的具體細節。本文中，對於spring所涉及到的模式，並非來自官方，可能某些地方會讓讀者感到牽強，純屬個人見解，希望讀者批判閱讀。

         我們將從討論BeanFactory和ApplicationContext的關係開始叩開spring的設計之門（實際上是AbstractApplicationContext和DefaultListableBeanFactory的關係）。簡言之，BeanFactory的核心作用就是建立bean，ApplicationContext的核心作用是建立BeanFactory並為我們提供統一的提供者。我們來看一下他們的類圖關係。

 

 

這裡省略了其他輔助介面，只留下二者的關係，以便於我們分析。我們可以這樣描述一下AbstractApplicationContext的作用：AbstractApplicationContext實際上是在用戶端和DefaultListableBeanFactory之間起到了中介的作用，也就是我們不能直接存取BeanFactory，而是要通過ApplicationContext來訪問。這樣就很明了了，代理模式的意圖正是如此。明確了BeanFactory和ApplicationContext之間的關係有助於我們在總體上把控架構的結構，不至於讓太多的介面搞的眼花繚亂。

         上文提到了，ApplicationContext的一個重要作用就是建立BeanFactory。BeanFactory的構建過程對我們來說是透明的，那麼我們有沒有什麼辦法擴充BeanFactory的行為嗎？這時候就涉及到BeanFactoryPostProcessor介面了。這個介面的作用是豐富，擴充BeanFactory功能。    

根據，這是一種設計模式嗎？是我在網路上找到了一個觀察者模式的url圖

  

我們是否可以描述一下的含義呢？多個BeanFactoryPostProcessor同時在觀察著DefaultListableBeanFactory的構建，一旦構建完成，就發送給所有的觀察者來豐富其功能。從這個思路來看這個是觀察者無疑了。我們在來看看責任鏈模式的結構圖。

 

 

責任鏈的一個主要特徵是：子類間構成一個鏈表結構。既然是鏈表，我們可以稍微改進一下，將鏈表改成數組。如果鏈表中的所有元素都執行。那麼責任鏈模式就便形成了如下結構

 

 

從這個角度來看BeanFactoryPostProcessor結構，更像是責任鏈模式。那麼他到底屬於哪種結構呢？從類圖上來分析，他更傾向於觀察者模式，但是意圖並不一致，觀察者的意圖是：當事件發生時，子類去更新各自的行為。比如下文要講到的ApplicationListener介面，但是這裡的意圖是豐富BeanFactory行為。如果從意圖上分析，更像是責任鏈模式。在一個鏈式結構中逐一豐富BeanFactory行為。只不過這裡把鏈表結構改成了數組結構。所以這裡的結論是：不知道。可能是觀察者，可能是責任鏈，也可能合并了二者，更有可能壓根什麼都不是。具體讀者自行定論。BeanPostProcessor介面也是以同樣的結構來豐富修改具體bean的構建過程。

         好了，現在bean工廠構建起來了。在建立xml中定義的bean對象前，BeanFactory第一個要做的事兒就是把xml中的各個標籤解析成BeanFactory能夠識別的BeanDefinition。

第一個問題：我們將以怎樣的方式來載入我們的xml檔案呢？更確切的，我們的xml可能是本地的一個檔案，也可能是在遠程下載的，還有可能已經存在於二進位記憶體中了。對於這些可能的情況，我們該怎樣抽象？進而怎樣載入到程式中？spring的做法是將這些可能的方式統一抽象為Resource介面，定義ResourceLoader介面專門來載入Resource。他們的關係如：

 

 

看出來了嗎？沒錯，spring用Factory 方法設計模式將xml檔案載入記憶體。當我們new一個ClassPathXmlApplicationContext開始使用spring的時候，實際上是選擇了載入方式，進而選擇了對應的資源模式。

第二個問題，資料已經載入到記憶體中了，我們接下來的目標自然是對xml檔案進行解析。如果你稍微有點spring使用經驗，就知道xml中除了<bean>標籤還有其他各種各樣的標籤，比如事務的，aop等等，有的讀者可能還想自訂滿足標籤。這怎麼辦？問題總是接踵而來，我們來看一下spring的處理方式，如

 

 

對於xml中不同的命名空間，spring用策略模式提供了完美的解決方案。如果你有興趣的話可以畫一下BeanDefinitionParse介面的結構圖。你會發現，他還是一個策略模式。需要注意的是,spring會自動掃描類路徑META-INF/spring.handlers設定檔來尋找相關策略實作類別。     

         至此，spring可以完全解析xml檔案了。接下來就可以大膽的建造我們配置的bean了。上文提到了，如果我們想要豐富，擴充，改變bean的構建過程。可以使用BeanPostProcessor介面。典型的AOP，代理，事務都是通過這個介面進行擴充的。我們的擴充點也在這裡。他的結構請參考BeanFactoryPostProcessor結構。

         Bean建立完成後，spring這個超大工廠加工工作基本完成了。這時候他會發送一個事件，通知關心相關介面。結構圖如下

 

 

沒有任何懸念，這個是觀察者模式的典型應用。

         這裡還要點到兩個設計模式，一個是模板方法。毫無疑問，spring的這種層層繼承結構大量的使用的模板方法。另一個是門面模式，

 

 

ApplicationContext把大量輔助介面統一在一起，為我們提供了統一門面。

         分析到此為止了。設計模式是我們學習各種架構的重要工具。識別是是哪種設計模式大體需要兩步，第一看“面相”，即類圖結構是否相似，第二看“心裡”，即意圖是否吻合。還是那句話，主要的不是我們看出了是哪種設計模式，最為重要的是我們在分析中的思維過程，在分析中學到的設計模式的具體使用方式以及對於對於不同問題的抽象過程。

java企業級通用許可權安全架構源碼 SpringMVC mybatis or hibernate+ehcache shiro druid bootstrap HTML5

【java架構源碼下載】

設計模式之spring分析 mysql oracle html5