論J-Hi平臺的特點
最近很多網友問我同樣的問題，那就是J-Hi與其它的平臺類產品有什么區別?它有哪些獨特的特點。實際在我看來J-Hi與目前任何其它平臺類的產品的出發點或稱之為初宗都是相同的，那就是想解決如何使開發更快速、更高效，如何降低項目的成本(不只是快速開發所帶來的成本降低，也包括項目的管理成本)。
總的來說，目前市場上的平臺類產品所采用的核心技術無非兩種，一種是模型驅動(后臺有一個模型引擎來負責解析與計算這些業務模型從而得到預期的運算結果);另一種是代碼生成(按照定義的模型通過生成器生成全部源文件)。從技術本身來看，這兩種技術都不算什么新鮮東西，只是隨著計算機運算能力的提高，相關技術的不斷成熟，使這兩種技術應用于業務開發平臺成為可能，因此單純從技術先進性來看，那我覺得都沒有什么在技術可以稱道的地方。反之，平臺它是多種技術的融合體，尤其是業務開發平臺不只包括技術本身還會包含一些通用的業務以及一些開發工具。因為這些的差異，就形成了各類平臺產品的差異性。在此讓我們來分析一下J-Hi Java快速開發平臺自身的特點(即與其它平臺的不同之處)：
快速的按需動態搭建
目前平臺支持的框架有：webwork、struts2、spring、hibernate、ibatis2、ibatis3，對于這些框架您可以通過可視化(J-HI Studio，eclipse插件)的方式隨意組合，通過工程創建向導，自動化的按照你所選擇的框架快速的動態搭建起開發工程。我們之所以將J-Hi做成多框架動態搭建，主要是考慮到不同企業的開發團隊對技術的傾向性會有很大差別，比如對于ORM有的人就喜歡hibernate，而有的人就覺得hibernate太強硬，喜歡用半自動化的ibatis。J-Hi基于這個目的為開發者提供了更多的可選擇性。在此要注意對于平臺多框架的集成并不象一般意思上的集成(即幾個框架拼接在一起就可以象appfuse一樣)，因為平臺的集成還要包括很多通用業務并且與數據庫表是有關系的(一般搭建多框架是沒有業務的所有的東西都要由你親自去開發，而平臺會有很多的業務已經預留在平臺中)。舉個例子：比如安全管理，這是平臺的一個通用業務包括角色、權限等。在切換到不同的框架比如struts或webwork;hibernate或ibatis時，平臺的底層要自動的適應這種變化，這是有一定的創新點的J。當然我們以后還會集成更多、更優秀的框架在平臺之中，比如SpringMVC，SpringJDBC等等，在數據庫端我們也會再多支持一些數據庫，當然集成數據庫也不是傳統意義上的只是一個數據庫連接，而是針對不同的數據庫差異會做不同的方言，不同的數據庫腳本還要有相應的生成模板等等。
因此你會發現快速按需動態搭建，并不是傳統意義上的多框架集成那么簡單，而是對應每一種框架(數據庫)平臺都會提供一套完整的解決方案。總之多框架集成對于J-Hi來說，是牽一發而動全身的事情，變動一個框架，包括每一個頁面，每一個java類，每一個配置文件都要隨之而動態的變化。因此它是系統級的工程而非簡單的多個框架拼接。
完整而系統的生成方案
代碼生成或生成器這實際上在十年前就已經有的東西，無論是實現原理還是具體的工具都不是新鮮事物。J-Hi之所以將代碼生成也算作自己的特色，是因為它的完整性與系統性。從完整性來看，J-Hi的生成是一套含蓋從數據庫底層一直到頁面端全部的解決方案，包括數據庫表;權限、菜單、多語言等相關基礎數據;java類文件;JSP、js文件;相關配置文件等等，因此保證了生成即可運行，從單元體上來看生成文件是完整的，是可獨立運行的。從系統性來看，生成的文件是隨著你選擇的框架不同而不同的，生成的基礎是隨著框架與數據庫的差異而隨需變化，系統的解決了生成器的僵硬性，從而靈活的適應開發環境。因此J-Hi的生成方案是系統的，是適應不同框架與數據庫的生成方案的。
平臺到底生成了些什么?
組件化
在軟件世界里組件這個概念真是千差萬別，每個系統與工具軟件對組件都有各自不同的定義。尤其在Java世界里更是如此，小的從一個頁面元素一直到大的一個業務功能系統，在各自的領域都會給它們定義為組件。按照《計算機百科全書》給組件的定義：是軟件系統中具有相對獨立功能、接口由契約指定、和語境有明顯依賴關系、可獨立部署、可組裝的軟件實體。由此定義我們來談一下J-Hi Java快速開發平臺對組件的理解與解決方案。
實際上說到底無非是對組件顆粒的劃分問題，在不同的條件與環境下組件的作用與功能會有很大差異，其次在定義組件時要保證功能的相對獨立并且可組裝可部署，由此J-Hi將組件根據用途與范圍的不同劃分為如下四類組件類型：技術組件、實體組件、業務組件、系統組件，它們之間的關系是逐級遞進，互為基礎的。
在我們在深入探討之前，先來簡單的解釋一下上圖中各種組件類型之間的關系。比如一個OA系統我們就可以把這理解為一個系統組件，而多個系統組件(倉儲系統、人力系統等)可以動態搭建更大的應用系統(ERP)。每個系統組件下會有多個業務組件，例如在OA系統下會有報銷單、會議管理等多個業務組件。因為大部分業務組件之間一般都是松藕合的，所業務組件可以無縫的遷移到其它的系統組件中，即實現業務組件可復用性。而在一個業務組件下會有一個或多個實體組件夠成，我們還以報銷單業務組件為例，在報銷單最少會有報銷單及報銷單明細兩個實體組件，一個實體您可以理解成與數據庫對應的一張表，實體之間可以繼承、一個實體可以有多個子實體。但實體不僅僅是數據庫表，它包括從頁面到數據庫表之間的全部代碼實現同時包括CURD所有操作的功能單元。對于實體組件我們會在后面詳細討論。***是技術組件，在J-Hi中技術組件可以說是一個抽象的概念，一個技術組件就是一個技術功能單元，它可能是一套生成模版，一個框架的支持，一套API(比如對短信、全文檢索的支持等)
實體組件：J-Hi將一個實體組件定義為一個集合單元，它不僅僅包括數據庫表還包括對該數據庫表的基礎操作(增、刪、查、改);包括前端的展示面頁;包括該實體的權限、菜單、配置信息;還包括它與其它實體的交互操作。當然一個實體組件顆粒度還是太小，還不能完整的描述一個業務功能。但實體組件相對來說有一定的獨立性，可以集成一個集合單元，J-Hi就是以實體組件為基礎實現更大粒度的集成，從而實現對一個完整業務的描述。
業務組件：實際上一個業務組件J-Hi將它對應于一個服務，服務可以認為是一個業務功能模塊，用以描述完整的業務模式，具體相對的業務獨立性。在服務內代碼間是高聚集的，因為一個服務就是一套完整的業務，在設計服務時應盡***限度的降低服務與服務之間的藕合度。因為在這個樣一個理論基礎上去設計，就可以實現業務組件無縫的在各系統之間的可移植性。因為組件的定義還要可以獨立的組裝與部署，因此我們開發平臺的附屬性產品——Hi平臺產品集成工具，它主要是由發布器與部署器組成，以更方便的實現業務組件的遷移。
開發發布器與部署器的目的就是通過可視化的方式，實現跨數據庫數據與跨應用系統的業務組件遷移。可以將業務組件看作一個獨立的業務單元，可以無縫的集成于任何以J-Hi平臺開發的項目中去。從而真正達到隨需組合，動態搭建實際的業務系統，真正的實現業務組件的復用，降低不必要的重復開發。
系統組件：從業務功能上來看系統組件不過是多個業務組件的拼接，更大一級的業務封裝。理論上系統組件與系統組件之間應滿足絕對的隔離性，即使是有通信，應該也是通過第三方來進行數據交互(常用的解決方式有兩種一種是中間數據庫;第二種是webservice)。但如果是基于平臺開發，這種無謂的工作量可以降低很少，甚至可以不需要第三方的交互技術。只要保證兩個系統間的通信接口就要以輕松實現。系統組件的遷移也可以通過發布器與部署器來實現。
技術組件：從技術角度來看，J-Hi與其它的技術組件差別不大。無非是基于平臺再開發一些技術組件，比如對 SpringMVC、SpringJDBC、DB2數據庫等的支持，頁面端也會再集成象DWZ或simpleframework，我們也會再提供更多的頁面端的生成模版，以此類推，平臺的技術組件會在技術的不同層面進行擴展。但與其它的技術組件不同之處在于，實現類似于插件一樣的可插拔，隨需織入。
【編輯推薦】
