Hasor 同 Spring OSGi 的比較及設計思想

    這篇是承接《輕量級 Java 開發框架 設計》系列Blog文的後續文章，本文將經過設計思想，實現方式上對比 Hasor Spring OSGi 三者。

    在開啓本文以前我想用最簡短的一段話介紹一下 Hasor 。

Hasor 它是一個 Java 應用開發框架，能夠說任何類型 Java 項目均可以使用 Hasor 進行開發。 它的設計思想是經過爲 Guice 構建了一個 Context 環境，而且配備了一套完善的插件擴展接口。剩下的全部功能都是由插件完成。

    不少朋友當看完上面這段介紹以後，腦海裏便浮出 OSGi。

    當 Hasor 第一次登臺 OSC 是經過一篇有關模塊化開發的文章開始，在一開始便有人將 Hasor 與 OSGi 進行了對比。因而也有人以爲 Hasor 毫不會是輕量級的。

    何況 OSGi 是企業級模塊化標準之一，而偏偏 Hasor 的首次亮相也是經過模塊化概念進行闡述。這也難怪 Hasor 從一開始就和 OSGi 有着解不開的關係。

    直到我加入一個小組討論中才發現，將 Hasor 看做是 OSGi 翻版的人並非少數。雖然我已經極力的介紹過它的架構和一些功能設計。可是不少朋友依然還認爲 Hasor 和 OSGi 比較類似。

    在設計 Hasor 以前我也研究過 OSGi ，其實從本質上 Hasor 和 OSGi 是根本不一樣的兩個東西。

    我我的以爲，Hasor 的架構思想和 Spring 是基本同樣的，都是在依賴注入控制反轉基礎上創建起的框架體系。而 Hasor 不一樣於 Spring 的是 Hasor 更注重插件接口，這樣的設計實際上是最小化 Hasor 的重要保證。

    由於咱們知道如今的 Spring 已經不是幾年前的 Spring ，它的功能逐漸變大加強，或許有些人認爲 Spring 在某些領域已經不能被稱之爲輕量級了。我猜測這最主要的緣由是項目依賴的 Jar 包太多了，動不動就幾十上百兆。

    Hasor 在初期注重插件接口，在這一部分 Hasor 走在 Spring 前面。也正是經過這種方式 Hasor 才能夠保證在未來功能增加時能夠保證形單影隻，最輕化。

    即便是如今 Hasor 具有了三大模塊，共計 14 個插件，累計 524 個類文件的時候，真正屬於 Hasor 的核心部件仍然只有最初的 45 個類文件。在包括註釋在內平均每一個類文件不會超過 400 行。其他全部類都是 Hasor 的插件，而插件是能夠被拋棄的。即便是將來的功能增加能促使 Hasor 更新核心類的地方也很難出現。

    所以我能夠確定的說 Hasor 自己是輕量級的！它毫不重！

--------------------------------------------------------------

1.OSGi 是一個插件平臺

    OSGi 瞭解它的朋友都知道，OSGi 有着一個完善的模塊化插件體系。OSGi 會爲每一個插件單獨分配一個獨立的 ClassLoader，而且 OSGi 還爲每一個插件提供了動態裝載，卸載以及熱部署的支持。

    若是你瞭解的更多會發現 OSGi 甚至能夠從你指定的 URL 地址中自動更新插件版本。並且它還能夠處理模塊多種版本同時存在狀況下的兼容問題。若是這還不算什麼的話，OSGi 還會帶給你更多驚喜。

2.OSGi 是一個服務平臺

    在 OSGi 中每一個插件均可以經過容器提供的接口向外發佈服務。同時插件也可使用其它插件發佈的服務。而這一切都是經過 OSGi 鏈接點完成。

    OSGi 鏈接點的使用是插件與插件之間溝通的主要媒介，這一點在使用上有點相似「依賴注入」，不一樣於傳統依賴注入的是 OSGi 當注入一個服務對象時候都會爲這個服務對象包裝一個代理層。正是有了這層代理層 OSGi 才能夠完成熱更新。一樣，藉助這層代理 OSGi 也提供了相同插件不一樣版本共存。

3.OSGi 是一個工業級的標準

    若是你對 OSGi 還有一點不清楚的話，我告訴你它是一個工業化的標準，一個真真正正的模塊化開發框架。它的模塊化體現到了方方面面。

    你能夠不用理會你的插件是否會引起 OSGi 容器運行的不穩定，也不用擔憂其它插件會影響到你程序的運行。而這一切正式經過 OSGi 完善的版本號管理來提供的。

    正由於如此你能夠在 OSGi 標準上同時讓一萬我的同時開發不一樣的插件，最後能夠穩定的集成到一塊兒。而這一切若是不是工業化的標準恐怕是很難實現的。也正由於如此 OSGi 給人感受過重了。

4.OSGi 與 Hasor 對比

    若是說 Hasor 還有資格和 OSGi 對比的話，我只能說 Hasor 也有插件。Hasor 經過擴展插件來擴充本身的功能。而這一切，只是創建在全部插件都要求實現 Module 接口的前提下。

    Hasor 也提供了模塊的依賴，這彷佛讓 Hasor 更加接近 OSGi 。但是 Hasor 模塊依賴管理，其本質只是爲全部插件提供一個初始化前後順序的配置方式。因此在一開始 Hasor 與 OSGi 就有着本質的差異。

    OSGi 會爲每一個插件提供一個獨立的 ClassLoader 。而 Hasor 要求全部插件類都必須能夠在同一個 ClassLoader 下找到。即便 Hasor 的插件支持 獨立 ClassLoader 這個功能恐怕也只能由一個 Hasor 插件在其插件上提供的「插件功能」。

5.Spring 與 Hasor 的類似

    輕量化 Java 開發框架 Spring 我以爲它絕對算得上輕量化，即便是如今我也認爲 Spring 依然是輕量化框架中的嬌嬌者。

    Hasor 與 Spring 從天生就註定很像，由於 Hasor 與 Spring 的核心思想是同樣的。都是基於依賴注入和控制反轉來構建整個架構。它們倆都經過 Context 爲整個應用程序構建基礎運行環境，也都是在 Context 上經過 IoC/Aop 爲應用程序提供基礎支持。

6.Hasor 是基於註解開發，而非 Xml

    Hasor 與 Spring 不一樣的是 Spring 牢牢環抱 Xml 配置文件。而 Hasor 則主要基於註解開發。在通常狀況下，使用 Hasor 開發應用程序不須要編寫任何配置文件，它是絕對零配置的。

    不過當你例如須要鏈接數據庫或者修改默認配置。也只好經過 Hasor 的配置文件進行配置了。除此以外您不須要經過配置文件註冊 Bean、Action、事務等等開發性的東西。

    Hasor 的配置文件主要是留給業務系統的，咱們每每在開發一個程序時常常會產生一些配置信息。通常狀況下咱們使用屬性文件去承載，這是因爲解析自定義 Xml 配置文件實在是繁瑣且必要性不大。Hasor 提供了一種統一的方式讀取自定義配置文件。

    這種方式使得開發者能夠擁有 Xml 那種結構化的表述，同時還保留了屬性文件那種簡單方便的特性。您能夠不編寫任何代碼直接從一個自定義配置文件中讀取到配置信息。而它的讀取方式卻和讀取屬性文件同樣。

    我猜測，實施人員會很喜歡這個特性。由於結構化的Xml 總比若干屬性文件來的更加直觀。即便是開發人員，也會從中獲得不少快樂。

7.Hasor 小，輕，快

   Hasor 與 Spring 同樣是一款輕量化框架，它甚至比 Spring 更加輕量。這一點不僅僅是從 Jar 包體積上體現。

    在 Hasor 中沒有 Spring 那種龐大的配置文件映射解析系統。我曾經嘗試開發一個與 Spring 類似的配置文件解析映射系統，當我完成了 300 個類規模的時候。我僅僅作到了Spring Beans、Spring Context兩個組成部分的解析。在 Hasor 中有關配置文件解析的類文件只有 12 個類文件。代碼總行數不過 1000 行，而這其中包括了 import 等元素。

    Hasor 沒有開發 IoC.Aop 部分，這一部分轉而是由 Google 公司出品的 Guice 工具提供。Guice 是一款輕量化 DI 工具。這個工具能夠說只是 JSR-330 的一個標準實現，除此以外 Guice 別無它用。

    單單一個 Guice 是沒法和 Spring 抗衡的，開發者若是想使用 Guice 去代替 Spring。也須要作不少工做以後才能完成遷移。這些工做固然不只僅是代碼上的改動。這主要是因爲 Guice 自己缺乏了 Spring Context 部分，而 Hasor 偏偏是在補充 Guice 確實的那部分。

    在 Guice 官網上咱們能夠看到 Guice 號稱快過 Spring 1000 倍。我想這個數據差別應該不只僅是啓動速度的體現把。

    Guice 在對 Bean進行依賴注入時不會預先的知道都須要哪些屬性須要注入，在它內部 Guice 使用了經典的 Visitor 模式當遇到 @Inject 時候纔去構建依賴注入的對象。這種設計會比 Spring 從其內部龐大的 Bean 定義元信息中解析數據來的更加直接，更加迅速。一樣的 Guice 也不須要經過容器管理 Bean 的生命週期，這也爲建立 Bean 提供了大量寶貴的性能。

8.Hasor 設計思想

    Hasor 堅持走輕量化路線，努力的保持其核心最小化。這個目標和 JFinal 有些接近。可是當 Hasor 要想保持本身輕盈，又想壯大功能時。免不了會與目標發生衝突，畢竟支持一個功能最起碼也是須要通過編碼的。這是一個瓶頸，也能夠說是一個軟件的設計邊界。

    許多開源軟件最終都走到這一邊界停下了本身的腳步，Hasor 試圖踏出這一邊界。因此 Hasor 最核心的問題是如何面對這個瓶頸。

    OSGi 的插件體系的確給了 Hasor 一些靈感。做爲 OSGi 最成功的項目 Eclipse 而言，整個Eclipse 都是由插件堆砌起來的若是將 Eclipse 中全部插件所有剔除，您會發現這隻能剩下一個 OSGi Context 程序。

    正是這個靈感，才促使 Hasor 有了一個突破口。

    假如 Hasor 的核心功能是 @Aop、@Event、@Controller、@Restful、@NeedCache、@Power.... 誰會曉得哪裏是個頭呢？

    一味的集成最後只能讓 Hasor 走到輕量化框架的邊緣，而後制住腳步等待後來者，最後與後來者一同埋葬在輕量化框架的墳場中。

    所以 Hasor 也採用 Context + Plugin 這種模式。重點放在 Plugin 接口如何設計而非 @Aop @Bean @Controller 的設計。

    Hasor 認爲，插件是靈活的而且極不可靠。永遠都有更加有效的 @Controller 來替代已存在的。所以 Hasor 當遇到 Web 時只會經過設計爲其提供一個 Web 下的插件開發接口。這樣一來全部 @Controller @Restful @Hessian @WebService @WebServlet @WebFilter 均可以插件形式在 Hasor 上運行。

    插件自己又不屬於 Hasor 有了這樣的保證，Hasor 才能夠放心大膽的去走出瓶頸，突破輕量化框架的邊界。而這一切到目前爲止還頗有成效。

    Hasor 目前包含了 Hasor-Core、Hasor-Web、Hasor-JDBC 三個部分，共計 14個插件，插件的數量仍在上升 Hasor 經過插件擴充本身的領域。也經過插件爲開發者提供更加友好的開發體驗。

    假如開發者不喜歡 Hasor 的 @Controller 開發者徹底能夠本身開發一個全新的將其取之。而 Hasor 自己卻不會受到任何影響。

    這就是 Hasor ，一個基於 Guice 的輕量化框架。利用它你能夠搭建本身的框架，利用它你能夠整合諸多技術。