Hasor：生命周期
為什么80%的碼農都做不了架構師？>>> ??
首先引用Wiki的介紹一下Hasor：
??? “Hasor是一款開源框架。它是為了解決企業模塊化開發中復雜性而創建的。Hasor遵循簡單的依賴、單一職責，在開發多模塊企業項目中更加有調理。然而Hasor的用途不僅僅限于多模塊項目開發。從簡單性、松耦合性的角度而言，任何Java應用都可以從中受益。Hasor與Struts,Hibernate等單層框架不同，它可以提供一個以統一、高效的、友好的方式構造整個應用程序。并且可以將這些單層框架建立起一個連貫的體系，可以說Hasor是一個搭建開發環境的框架。這一點與Spring比較相似，您可以理解Hasor可以作為Spring之外的一種選擇。”
??? 昨天忙乎到很晚終于確定了Hasor一個明確的啟動過程。目前啟動過程已經設計的比較清晰了，相比以前凌亂的設計顯得優雅許多。接下來就是要對hasor做“手術”實現它們了，在這里首先將其設計思想介紹給大家。
主要結構：
在介紹Hasor生命周期之前先要說明的是在hasor中其主要的部分有三個：配置文件處理(Settings)、應用環境上下文(AppContext)、Guice3.0增強(ApiBinder)。在整個啟動生命周期中上述三個部分可以使用的順序是Settings->ApiBinder->Context。下面這張圖羅列了Hasor核心接口功能和這三個部分的依賴關系：? ? 上圖中詳細的羅列出Hasor的主要功能及其依賴關系。圖中紅色部分是Hasor的三個最基本部件，可以看出Settings、ApiBinder、AppContext三者是一個遞進的關系。在Hasor啟動生命周期中也是如此，當你可以使用ApiBinder時就意味著你此時不能使用AppContext，只能使用Setting相關功能。下面是各個部件的介紹。
Settings部件
Xml映射方式
? ? 在Hasor中Settings接口主要負責配置文件的解析工作。Settings提供了一種統一的方式解析Xml，它會將Xml的所有數據按照Xpath的路徑轉變成為Key/Value鍵值對并以Map形式保存。例如Xml配置和映射關系如下：
? ? 注意1：當你的標簽屬性名和子元素名重名時Settings并不能有效的區分它們，此時你應當獲得標簽的?XmlProperty?接口使用DOM方式來獲取你想要的東西。我不推薦將Xml標簽的屬性名和子標簽使用相同名稱。這樣做會很容易混淆對Xml配置的理解。試想當你在看到一個標簽有enable屬性同時又看到子標簽也有一個enable時，你一定不會第一時間知道哪個才是真正的啟用禁用設置項。
? ? 注意2：使用Key/Value鍵值對獲取配置信息時Settings會忽略大小寫敏感。在上面的例子中使用“loginsafe.enable” 或 “LOINGSAFE.ENABLE” 都可以獲取到映射的屬性值 “true”。
DOM方式操作配置文件
? ? 在Hasor中使用Settings接口嘗試獲取的Xml配置項如果是一個標簽元素那么可以采用getXmlProperty()方法獲取XmlProperty接口對象，該接口對象提供XML的DOM操作。
ApiBinder部件
??? ApiBinder接口的設計初衷是負責提供模塊啟動過程中在AppContext尚未形成時的支持，這其中包含了Guice的Binder接口。用過Guice的朋友一定會熟悉Guice在Binder接口上提供了各種綁定的功能，當然這包括了定義Aop。詳細有關Guice3.0的介紹您可以到Guice官方網站查看。Hasor不會直接提供給開發者Guice的Binder接口，不過開發者可以通過ApiBinder接口來獲取Binder接口，這正式ApiBinder接口的作用之一。通過ApiBinder可以得到Settings及其相關部件的各種功能。此外注冊Bean也是由ApiBinder提供。需要注意的是“ApiBinder接口僅僅在OnInit生命周期階段有效”因為此時正在調用Guice.createInjector方法創建Injector對象，所以請不要將ApiBinder接口的引用保留到OnInit階段之外，那樣做是不安全的。
AppContext部件
? ? AppContext接口負責支撐整個Hasor平臺的運行，通過AppContext你可以輕松的管理當前系統的所有已加載模塊，而且還可以像Spring一樣通過服務名獲取服務實例。AppContext提供了階段性心跳事件（Timer）的支持。更多的AppContext信息請參看相關文檔。
啟動過程與模塊生命周期
? ? 經過上面的介紹想必讀者對Hasor的核心部件有了一定的了解。本文的最終目的是為了闡述Hasor的生命周期從啟動到銷毀各個階段都做了什么、能做什么！那么下文正式開始闡述生命周期相關內容。右邊的圖展示了（Hasor生命周期、Hasor事件、模塊生命周期）三者之間的關系。
- load ns.prop 階段（一）
? ? 該階段是創建Settings部件的必要過程，目的是為了Settings即將執行的Xml解析做準備。該階段會讀取classpath路徑中所有“ns.prop”屬性文件，并裝載該文件中定義的Xml命名空間和對應的解析器匯總到一起注冊到Hasor特有的Xml解析工具上。通過這個工具不同的命名空間解析器會收到屬于它們命名空間下的Xml事件流。
提示：并雖然Hasor支持對每個模塊都有可以有自己的Xml命名空間，但是我更建議使用不同的Xml標簽作為模塊配置內容的分界。
（Hasor的Xml解析工具用的是Stax方式處理Xml并將解析結果轉換為類似Sax的事件流，該工具可以將Xml事件流分割到不同的命名空間）
- load Config.xml 階段（二）
? ? 該階段是創建Settings部件的必要過程，主要目的是為了解析裝載Xml配置文件。在Hasor中配置文件被分為兩類：主配置文件(config.xml)和靜態配置文件(static-config.xml)。Settings會在運行時監控config.xml配置文件的變化；并且自動重載變化的config.xml，而static-config.xml就不支持這種特性。在該階段其具體處理過程分為如下三步：
? ? 第一步：處理"static-config.xml"配置文件，使其生成一組Key/Value鍵值對（使用Map封裝）。
? ? 第二步：用同樣的方式載入“config.xml”，但是與處理“static-config.xml不同的是處理“config.xml”不需要考慮classpath中存在多個“config.xml”的情況。并且將config.xml解析的最終結果合并并覆蓋第一步產生的結果中。
? ? 第三步：裝載“config-mapping.properties”屬性文件，該屬性文件的作用是為某個Settings配置項目起一個別名。在配置文件升級時該功能可以有效的將老配置項移植到新版配置文件上。值得注意的是當起的別名和現有配置項目遇到沖突時，Settings會拋出一條警告，同時放棄這條記錄的處理。
提示：目前Hasor還不支持XSD驗證功能。
- do Start 階段（三）
? ? 這個階段，會引發（OnInit、OnStart）兩個事件。由這兩個事件分別處理模塊中對應的OnInit和OnStart生命周期方法。模塊通過OnInit階段可以利用ApiBinder接口在初始化階段完成一系的綁定工作，而后當所有模塊都初始化完畢之后在通過OnStart階段完成后續操作。
- Run 階段（四）
? ? 該階段當所有模塊都已經完成初始化并且啟動之后進入該狀態，在Run階段Hasor會定時觸發一次Timer事件。開發人員可以利用Timer處理一些應用程序運行中的小任務。開發人員可以通過ApiBinder或者注冊AppEvent監聽器來使用這個功能。
- do Stop 階段（五）
? ? 通過調用stop或destroy方法可以引發該階段的階段性事件。OnStop事件會被傳播到所有模塊，用以通知模塊停止服務的提供。此外start方法還可以將已經處于停止運行下的服務start方法重新啟動。
- do Destroy 階段（六）
? ? destroy方法可以引發該階段，該階段標志著整個App應用被銷毀。被銷毀的應用程序不會接受再次啟動。
生命周期狀態轉換
項目主頁：http://www.oschina.net/p/hasor
項目托管地址：https://github.com/zycgit/hasor
作者郵箱：zyc@hasor.net
轉載于:https://my.oschina.net/ta8210/blog/143873
總結
以上是生活随笔為你收集整理的Hasor：生命周期的全部內容，希望文章能夠幫你解決所遇到的問題。
