張昊

2. 這項技術有什么優點?是否已經在實踐中證實呢?

3. 哪些領域能運用這項技術，您能有一些好的建議么?

4. 對于剛剛接觸J-HI這項技術的人群，有什么好的學習建議

       J-Hi設計自己的查詢過濾器而沒有直接采用Hibernate的Criteria，是出于以下兩個原因：

1、Hibernate的Criteria的功能是很強大，但在使用上還是比較繁瑣。因此J-Hi想從用戶使用的簡單易用性上考慮設計一款查詢過濾器。

2、J-Hi是一款跨ORM的多框架平臺，不能拘泥一種只在Hibernate適用的產品。因此從設計角度考慮，J-Hi對于查詢過濾功能必須要有一個中間層，從而使適應多ORM框架成為可能。

       下面讓我們來分析一下對于SQL的查詢具體應該考慮些什么

1、                                          1、字段名            數據庫表的字段名

2、                                          2、操作符            比如大于、小于……。還會包括一些特殊的操作符如like和in

3、                                          3、NO                 NO操作符是對操作符的補充，只有in和lik也會有no

4、                                          4、值                   對應字段類型的具體值，如字符串就要加引號，日期就要做轉換

5、                                          5、空值               空值是特殊值，表述形式如IS NULL或IS NOT NULL

6、                                          6、關系符            兩個查詢條件之間的關系包括三種 AND OR NOT

7、                                          7、優前級            通過左右括號來控制查詢條件的優前級

8、                                          8、通配符            如果是like操作符，在值的左側或是右側或兩側都可以通過%來控制值的匹配條件

對于java來說，無非就是考慮如何將上述的描述通過對象化的方式實現

先讓我們用例說明：

       Filter filter = FilterFactory.getSimpleFilter("name", "馬超");

首先所有的過濾器都必須由FilterFactory(過濾器工廠)創建，參數依次為

name：POJO的屬性名的字符串,可以通過.級聯如(org.id);

value：待過濾的過濾值

oprtion：操作符，提供多種操作符，具體參見javadoc

relation：關系符，兩個過濾器之間的關系，如AND / OR / NOT

過濾器可以通過addCondition方法累加過濾條件，例如：

filter.addCondition("name", "趙云", Filter.OPERATOR_EQ,Filter.RELATION_OR);

調用addCondtion()方法返回是條件累加后的Filter，因此你可以一直不斷的調用addCondtion()方法，而不用每做一個過濾條件就創建一個新的Flter。

也可以通過addFilter方法將兩個過濾器連接合并在一起

       otherFilter.addFilter(filter, Filter.RELATION_AND);

因為一個過濾器會有多個查詢條件，因此在通過addFilter()將兩上過濾器進行合并時會對這兩個過濾器自動加左右括號。對應sql為：

(otherFilter的查詢條件) and (name like ‘%馬超%’ or name = ‘趙云’ )

       與addFilter對應，J-Hi還提供了removeFilter的功能，目的是通過目標過濾器中刪除曾經加進來的子過濾器

              otherFilter.remove(filter);

       對字符串的操作，如果不加操作符那么系統默認采用like操作符，并且左右兩側均會加通配符，為了解決通配符的問題，J-Hi提供了

Filter likeFilter = FilterFactory.getLikeFilter("name", "馬超", Filter.RELATION_AND, LikeFilter. LIKE_CONTROLER_LEFT );

對應的SQL語名為：name like ‘%馬超’

       如果對null或非null做過濾

     FilterFactory.getSimpleFilter(propertyName, null, Filter.OPERATOR_EQ);

FilterFactory.getSimpleFilter(propertyName, null, Filter.OPERATOR_NOT_EQ);

對應的SQL語句分別為：propertyName IS NULL ; propertyName IS NOT NULL

如果做包含(IN)做過濾

FilterFactory.getInFilter(propertyName, coll);

其中coll是java.util.Collection接口的對象

除此以外，J-Hi還提供了排序器

Sorter sorter = SorterFactory.getSimpleSort(propertyName, Sorter.ORDER_DESC);

Sorter.addSort(properyName1, Sorter.ORDER_ASC);

首先所有的排序器都必須由SorterFactory(過濾器工廠)創建，排序器可以通過addSort方法累加。也可以通過addSort方法將兩個排序器連接合并在一起

具體的調用方法例如：

HiUserManager userMgr = (HiUserManager)SpringContextHolder.getBean(HiUser.class);

userMger.getObjects(filter,sorter);

總結：J-Hi的查詢過濾器并沒有象Hibernate的Criteria那么的強大，還不支持外連接與聚合。原因是這種大數據量的統計對ORM框架來實現在效率上并不是好的解決方案，再者實現上述功能增加了使用者操作的復雜度。薦于以上兩個原因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的生成方案是系統的，是適應不同框架與數據庫的生成方案的。

平臺到底生成了些什么？

組件化

J-Hi把組件劃分為四類，技術組件、實體組件、業務組件與系統組件，具體內容請參見平臺組件化

      自J-Hi正式發布以來（2011-1-14）已有三百多個愛好者加入我們的交流群，下載次數約1300次。隨著使用者的增加逐漸增多，大家在使用中的疑問也越來越多。其中最多的問題就是生成器到底生成了些什么東西，下面以xxx服務，實體***為例，對生成的文件一一講解：

數據庫相關

對應不同的數據庫J-Hi會生成不同的數據庫腳本文件，生成的文件會臨時存放在web/db目錄下的相關數據庫（MSSQL/MYSQL/ORACLE）子目錄下，每次生成該目錄下的文件都會清理一次。生成的文件如下：

xxx.sql    定義該服務下所有實體（枚舉實體除外）的數據庫表的創建

xxx_BaseData.sql用于對該服務下的實體，為系統表插入相關數據,系統表包括：菜單、權限、枚舉等，通過該文件會將與實體相關的菜單信息，權限信息等一次性的插入到系統表中

Java相關

       因為Java含蓋的框架有很多，采用不同的框架不同的技術生成的內容會有所不同，下面讓我們按三層結構的原理劃分說明：

數據訪問層

       xxx.dao包為數據訪問層的總包，對應不同的ORM框架還會有相應的子包，比如hibernate、ibatis(ibatis2)、ibatis3等子包。

       ***DAO.java：在dao包下這是個接口，用于規范不同框架之間的差異。

       hibernate子包：

***DAOHibernate.java：hibernate數據訪問的具體實現類，該類繼承BaseDAOHibernate，從而實現對hibernate的封裝

***.hbm.xml：該文件是hibernate的映射文件

       我們之所以把ibatis的兩個不同版本分兩個子包來管理，是因為ibatis2與ibatis3在底層實現上已經有很大的差異，無論是內部運行原理還是配置文件基本上是顛覆性的變化。

       ibatis子包

              ***DAOIbatis.java：ibatis2數據訪問的具實體現類，該類繼承BaseDAOIbatis，從而實現對Ibatis2的封裝

              ***.ism.xml：ibatis2的映射文件，之所以后綴叫ism是指ibatis sql mapping

      ibatis3子包

              ***DAOIbatis3.java：ibatis3數據訪問的具實體現類，該類繼承BaseDAOIbatis，從而實現對Ibatis3的封裝

              ***.ism3.xml：ibatis3的映射文件，之所以后綴叫ism是指ibatis3 sql mapping

業務邏輯層

       業務邏輯層J-Hi采用的是spring，因此大體上與spring的標準結構完全相同

       xxx.service包為業務邏輯層的總包，接口定義在該包下

       ***Manager.java：業務邏輯的接口類文件，缺省生成的是實體的增刪查改方法，如果在業務邏輯層中想做權限控制，可以調用*Security***()方法

       xxx.service.impl包下的

       ***ManagerImpl.java：是業務邏輯的具體類，該類繼承ManagerImpl類。如果是特定的業務邏輯一定要在該類中通過手寫代碼的形式實現之

       appContext-xxx.xml：是spring的配置文件，放在置在xxx包下

表現層

       xxx.action包為表現層的總包，對應不同的表現層框架會有相應的子包，比如webwork、struts等子包。

       ***PageInfo.java：在action總包下，該類是與框架無關的，實際上該類記錄頁面信息的一個POJO，信息主要包括三部分：1）翻頁（page）：行數、當前頁數等；2)過濾器(filter)：即查詢條件；3）排序器(sorter)：即正序倒序

       webwork子包：

***ListAction.java：查詢頁面時所調用的動作

***.RemoveActoin.java：刪除記錄時所調用的動作

***.RemoveAllActoin.java：批量刪除時所調用的動作

***SaveAction.java：保存記錄時所調用的動作

***.ViewAllActoin.java：查看記錄時所調用的動作

xwork-xxx.xml：webwork的配置文件

       與webwork相比，struts的類文件只有一個，所以的動作都是通過方法命名調用實現的，我們之所以做成兩種生成方式，是想考慮用戶會有個自不同的編程偏好，從而我們為些在不同框架間提供兩種生成模式，以適應這種編程偏好的差異

       struts子包：

       平臺目前舍棄了對struts1.x的支持，所以與struts相關都是以struts2為前提的

       ***Action.java：該Action包括了所有的頁面調用動作，通過方法命名進行調度

       struts-xxx.xml：struts2的配置文件

POJO及其它

       在xxx.model包為POJO的總包，一個POJO實際上是由兩個類文件組成的，即

       ***Abstract.java：該類是POJO的抽象類

       ***.java：該類是POJO的具體類

       之所以這樣做是為了避免手寫的代碼會被生成器生成的文件所覆蓋

       ***.java：如果在定義是有枚舉實體，在model包下還有會生對應枚舉實體的常量類文件

       ***-conversion.properties：如果實體有從實體，也就是主從結構，生成器對應主實體生成該文件，其目的是為了適應表現層框架對頁面信息的對象化封裝

       xxx--security.properties：該文件放置在xxx包下，是權限的映射信息的配置文件

頁面相關

       以后生成器會根據所選模版不同，而對應生成的頁面會有很大差異，現在以目前平臺的經典模版為例

       ***List.jsp：查詢頁面

       ***Edit.jsp：編輯頁面

       ***View.jsp：查看頁面

       ***.js：與JSP文件應對應的javascript文件

源數據相關

       ***.hsc.xml 對應每個服務，平臺在WEB-INF/matadate目錄下都會生成一個源數據的描述文件。該文件記錄了定義了模型的全部信息。hsc的意義為：hi service config

基于平臺生成器避免手動代碼被覆蓋的解決方案

如果您采用本平臺開發，理論上80%以上的代碼都是生成出來的。這樣就帶來了一個新問題—如何保證我手動改寫或添加的代碼不會被生成器生成的文件所覆蓋?

考慮到上述問題生成器在生成文件時有如下規則：

生成器會反復生成并覆蓋以下類與文件：

  i.        model.original包下的抽象類

  ii.        action包下***PageInfo類

  iii.        model包下的***.hbm.xml文件

  iv.        服務根包下的appContext-***.xml文件

  v.        服務根包下的***-security.properties文件

  vi.        src根下的xwork-***.xml文件

除上述文件外，生成器對生成其它文件時均會判斷是否以存在，如果存生就不再生成也不會覆蓋已生成或手動修改類或配置文件的內容

從反復生成的文件規則上可以看出，生成器只會反復生成：

1）  與實體屬性密切相關的類或配置文件如模型的抽象類與***PageInfo、***.hbm.xml，因為實體中的屬性名稱或數量發生變化，生成器要適應對實體屬性的變化

2）  與整個服務相關的配置文件如xwork-***.xml、appContext-***.xml等等，因為一個服務下會有多個實體，生成器要適應服務下實體數據庫的增減

3）  對于那些與實體相關并且不與服務或實體屬性相關的類生成器卻只會生成一次如dao、service、action下的所有類，以保證您手寫的代碼不會被生成器所覆蓋

在基于平臺開發時，因采用生成器生成所以可以使用如下解決方案來避免您手寫的代碼或配置不會被生成器所覆蓋

               i.      如果您要對模型類實現某個接口或方法，請改寫model包下的具體類，該類只會生成一次，注意千萬不要修改original包下抽象中的內容

                ii.      如果您要對表現層的配置文件做修改，以xwork-test.xml為例，操作應該是1）新建一個xwork-test-customer.xml配置文 件，2）將您要修改或要增加的actoin寫在該文件中(即使action名與xwork-test.xml只的action名重復也沒有關系，系統會以 您的action為最高優先級)，3）在xwork.xml文件中引入該配置文件<include file="xwork-test-customer.xml" />注意一定要放在xwork-customer.xml引用的下面。只有這樣復名的action才會優先調用您的配置

                iii.      如果您要對業務層的配置文件做修改，以appContext-text.xml為例，操作應該是1)新建一個appContext-test- customer.xml配置文件，2）在該文件中加入您自己的配置信息。注意新建的文件名必須以appContext開頭。

               iv.      如果您要對權限配置文件做修改，以test-security.properties為例，操作應該是1)新建一個test-customer- security.properties配置文件，2）在該文件中加入您的配置信息。注意新建的文件名必須以-security結尾。最后如果您想刪除生 成的配置文件中某些配置項（即對某些url或方法不要求做權限控制），推薦在整個項目做完后統一處理。

初入江湖

在我看來程序員這一職業所走過的道路，就象我們每個人心目那個魂牽夢系的江湖。初入江湖時只是一個根骨不錯全無武功，但夢想成為一代大俠的毛頭小子，這時最想得到的是一把舉世無雙的神兵利器，以為有了它就可以揚名立萬創下不世的功業。這就好比一個想成為程序員只會了一點點java基礎的剛出校門的學生，懷揣著自己人生的夢想躊躇滿志的步入社會，而對他來說第一要用到的兵器就是Eclipse。因此對于我們程序員來說一上手就有一件神兵利器是一件幸事，然后真正能達到運用之妙，存乎一心的地步還是因人而異；

投入門派

選好了兵器后步入江湖的第二件事情就是要加入一個門派；因為在java世界里會有很多分支，有做手機或PDA的javaME，做網站或是企業級開發的JavaEE，這就好比武林中的各各門派，門派的不同功夫的套路、思想都會有很大的差別，一般來說江湖中的俠士們加入門派后都不會另投它派，程序員也一樣選擇了一個領域就很少有機會再涉足其它領域，所以選好門派是職業生涯中的一件大事，不可含糊。在武俠的世界里進入門派后一定是不分寒暑的苦練武功，可能會有拳術、劍術、棍術、槍術等等總之十八般武藝樣樣精通（象少林寺中的覺遠，哈哈）；而在程序員的世界中也是一樣，你要學會很多的框架，這些框架也會分為不同的類別，比如表現層的struts或webwork、數據訪問層的hibernate或ibatis、業務邏輯層的spring與xml對象化交互的JAXB等等。真是套路繁雜，學無止境，看著一本本厚厚的能拍死自己的技術書籍，真是苦不堪言，然而正所謂師傅領進門修行在個人，更主要的是自己要日日精進，勤學苦練才能學到真正上層的武功。

內功修為

隨著武功的境界的不斷提高，一個闖蕩江湖的大俠會逐漸發現功夫套路習得的多少對自己的功力并沒有多大長進了，越來越發現內力的提升才是根本，而套路不過是枝葉而已；程序員也是一樣隨著學習框架的增加，會越來越關心設計思想的重要性，發現語言本身不過是思想的一種載體而已，用什么語言去實現已顯得不那么重要，真正的達到“手中無劍，心中有劍”的上層功力。隨著武功的精進內力修為的提高，逐漸會發現設計模式也不過是一種解決特定問題的一種設計方式，甚至是成為了一種思維定式，遇到問題會不加思索的會聯想到指定的設計模式，真正的達到“手中無劍，心中亦無劍”。如果是做企業級開發的程序員會越來越關注于企業級開發的整體模式，發現像權限、工作流等等這些功能無非是千篇一律有模式可尋的東西。當發現這些規律并能充分利用好它們時就可以達到“重劍無鋒，大巧不工”這種武功的最高境界。

俠之大者

       最后我想要說的就引用金庸大俠在《神雕俠侶》里面的一句原話吧，“俠之大者，為國為民”，對于J-HI平臺它是免費的、開源的，我們整個團隊希望為中國的開源事業盡到自己的一份綿薄之力，也希望大家在看過這本書后都能有自己的收獲，也許這種收獲不只是在技術上還包括對編程的熱愛，對中國開源事業的熱愛以及一個團隊那顆顆熱誠的心。

http://www.j-hi.net

J-Hi平臺的市場定位與目標用戶是什么？競爭對手又有哪些？

J-Hi自 誕生 之日起就把目標定位在如何解決開發的高效性上，這是我們的初衷也是我們的最終目的，對于高效性J-Hi對此的解決方案是：

1）易于上手，學習成本低：J-Hi沒有自己的標準，J-Hi是標準的執行者與推廣者。因此我們采用的都是大家很熟悉的成熟技術，如spring、hibernate、struts、ibaties、webwork

2）代碼生成的方式：說到底J-Hi是程序員給程序員開發的工具，因為只有這樣才會使項目開發更可控（從技術本身來說沒有萬能的工具，只有coding才是萬能的）。J-Hi是想使程序員從千篇一律而又枯燥繁瑣的重復代碼中解放出來，通過代碼生成的方式由生成器全部生成，而使開發人員把精力更多的去放在關注業務本身上。

3）平臺的底層支撐：從技術上我們在J-Hi與其它框架的整合上做了一些工作，目的是使開發人員更方便的去調用，使代碼編寫起來更高效。而且不同框架的組合是動態搭建的，從而使您有更多的選擇性，更適合開發人員的技術掌握情況。從業務上J-Hi提供了一些抽象的業務組件，比如組織機構、權限、菜單、任務調度、枚舉（數據字典）、日志等等。

4）組件化模式：J-Hi認為每個服務就是一個業務組件，業務組件可以在不同的系統之間來回遷移，從而實現業務組件的復用性。從另一方面來看，也更有利于公司的技術與業務積累，不用做重復的工作。對于組件化我們會提供完整的文章后續討論。

5）基于使項目管理更規范，從而使項目的開發更高效：因為代碼生成所有的層次結構與編寫方式都是規范的（即使是一個屬性名），因此更方便開發人員的相互溝通與閱讀，也是因為這個原因從而使人員流動的風險大大降低（繼任者可以很快的讀懂別人寫的代碼，很快的投入到工作中去。誠然新來的人還要了解業務，但對于開發人員來說他只要關心自己一部分的業務需求，而不用整個系統去了解需求）。

6）現在項目開發最大的問題是開發與文檔的不同步：目前我們在這一部分已有自己的解決方案，但因為精力與資源有限還沒有形成真正的產品化的東西L

對于J-Hi來說目標用戶主要是中小型及大型但技術積累不足的軟件公司和系統集成商。說到競爭對手，因為J-Hi是開源的，既然開源就應該抱著一個開放的心態我們沒有真正的競爭對手。如果真說有的話，我想應該是想舍棄程序員實現非編碼開發的產品吧！

J-Hi的有何創新點？優勢又在哪里？

在說到創新點之前我想先說一下我們對創新的理解，什么是創新，我們覺得不過是在前人的基礎上前進了那么一小步，大部分還是吃著前人嚼過的饃。我覺得Spring 的AOP在目前的主流技術里是最有創新的，但分析到最底層時也不過是動態代理（不過能運用到如此程度也不得不讓人敬佩的五體投地）。嚴格意義的說平臺沒有創新只不過是十多年開發的經驗積累，即便是有創新也只是對各種技術的融合，也是通過這種融合使使用者有更多的選擇性。目前我們正在做與國內優秀框架的融合工作，包括DWZ和simpleframework。以后我們也會秉承這種思想，融合更多更優秀的東西加到J-Hi之中去。

對于J-Hi你們想怎樣運作？是商業運作嗎？

       是的，我們是商業。原因很簡單在中國的開源大環境不好。象在國外一般都會有一些基金的支助或是代碼捐贈，但中國現在我還沒發現。大家都是興趣，是對編程的一種熱愛，而且大多都是兼職在做。我覺得大家的出發點都是好的但是可操作性太差，因為沒有商業運作就很難提供優質的服務，沒有好的服務也就抑制了產品的推廣，沒了用戶群產品就不會有旺盛的生命力。我最大的愿望是：中國的開源團隊聯合起來！

那你們想如何通過平臺盈利呢？

       現在我們想到的主要是通過服務與技術支持，當然J-Hi以后要走的路還很長，以后還要很多的事情要做，比如基于平臺的增值組件，我們把增值組件劃分為三種形式：

1、  開源組件：比如CRM、CMS、進銷存等

2、  免費組件：比如：SpringMVC、SpringJDBC等

3、  收費組件：比如：報表系統、在線會議、工作流等

這么多的工作你們幾個怎么可能完成呢？

我們的想法是J-Hi不只是一個開發工具，更是一個開放的生態社區，希望大家都能融入進來，也許前期我們會有一些投入，但我們的目的是想讓更多的人加入到這個社區中來，大家共同工作，從而實現雙贏，使每個付出的人都有收益。

你們的工作流為什么不開源？

       是就這個問題有很多的朋友問過我，有人還說我們是假開源偽開源。也許他們說得也有道理，但中國的開源環境我們也是沒有辦法的事。總不能餓著肚子做開源吧，生存是目前擺在我們團隊最大的問題，如果生存都成問題，那還怎么可能把事情做下去呢。所以對此還請大家諒見，工作流開源對我們來說只是遲早的問題，而不是想著死抱著不放。

趨勢

在當今的企業級開發過程中隨著開源框架的不斷成熟(穩定性與可維護性已不是問題)，如何快速提高開發效率,降低開發成本已成為急待解決的問題。為了解決上述問題各各大型的軟件公司或是有五年以上經驗積累的中、小型軟件公司都會有各自的解決方案?；蚴侵贫ㄍ暾拈_發方案；或是有一個帶一些業務的框架；或是有自己的開發工具。在這個大環境的驅動下也不乏一些專做開發平臺的公司應運而生。究其原因，這是一種趨勢，我們認為軟件行業正在走著一條硬件的老路，在此我們先回顧一下硬件的發展道路

通過圖不言自明，硬件正是通過是獨立的單元不斷向更大的集成的趨勢，每個上一環節都是下一環節的單位，而下一環節是上一環節更大規模的集成。從本質上來看軟件也與硬件的道路差不太多，如圖：

融合

如果從嚴格的意義來說J-Hi沒有什么創新點，技術創新不過是在前人的基礎上多前進那么一小步，因此即便是有創新點也只是對各種技術的融合。有人說這叫“造輪子”，我們不想造輪子，也不想提出自己的開發規范。J-Hi的關注點主要制力于對優秀的框架與技術進行融合，使其更適合方便的使用。因此J-Hi是開放的，不同與其它以模型驅動的業務平臺產品有自己的開發規則、腳本語言與操作方式成為了一個自封閉的系統。又因為J-Hi的開放性，利用的都是主流框架的開發規則(這些框架大家都耳熟能詳，基礎知識已不是問題)，從而降低開發人員的學習曲線，提高了開發速度。平臺的開放性也注定了它會不斷的融入進的元素，加入新的框架。不斷的求新、求變、保證性能的穩定與功能的完善是它追求的目標。嗨！~~，象打個招呼這般簡單實用是它的源動力（J-Hi名字的由來）。

尊重傳統的開發模式

       程序開發是一種習慣，看慣了代碼、寫慣了coding，程序員很難接受無編碼的開發形式，沒了設計感覺扼殺了自己的創造力。而J-Hi完全尊重傳統的開發模式，可以說是對傳統開發模式的有益補充，補充在代碼生成與組件的可移植性上。首先，是生成可以使您從枯燥的復重勞動中解放出來使您將精力更多的用于把握客戶的業務需求；其次，所有代碼無論是生成的還是底層代碼都是對您可見的，您可以充分發揮你的創造力與創新精神，采用設計模式寫出優質的代碼；最后，平臺的組件化更便于您與其它系統的整合（例如您在OA里做了一個報銷管理，您可以通過發布器方便的將它移植到ERP系統或任何采用平臺開發的系統中去）。

所有的一切只是為了提高速度降低成本

Hi平臺的宗旨無非八個字“提高速度，降低成本”，在提高開發速度方面：

1）      Hi平臺采用模式代碼生成的方式會生成從數據庫腳本、JAVA代碼、JSP頁面到相關配置文件所有文件，從而使您從枯燥繁瑣的編輯配置文件寫模式代的JAVA代碼中解放出來。

2）      平臺本身提供了很多通用的、可配置的功能模塊（如權限管理、附件、枚舉管理……）我們稱之為通用組件。因為這些通用組件都是十分常用的，可以說在一個系統中它們無處不在，所以利用通用組件可以大大加快項目的開發速度。

3）      Hi平臺底層是一個設計良好的框架，可以說融入了當今大多數主流的開源框架。通過向導的形式平臺可以提供對不同框架間的一站式快速搭建。

4）      除之以外如何快速響應客戶的需求的不斷變化一直是做軟件項目的一場噩夢，而Hi平臺在這方面有一些自己的經驗與嘗試，即使是增、改數據庫表字平臺本身也有自己的解決方案。

在降低成本方面：

1）   風險成本，為了提供開發速度降低項目的經濟成本采用平臺或工具(即使是采用一些開源框架)這已是業界不可逆轉的趨勢。隨著平臺化產品的不斷涌現，如何選擇好的產品以降低風險已是作為決策層首當其沖考慮的問題。在這方面可以說Hi平臺在同類的產品中風險是最低的，一、它是開源的沒有任何瓶勁；二、它是代碼生成的所有的一切均可見，J-Hi平臺不發現制造規范只是java世界中主流規范的執行者，本身沒有任何技術陷阱；三、可以說J-Hi平臺是程序員為程序員開發的一個工具，它的開發模式與傳統開發模式完全相同

2）   人力成本，快速開發本身就意味著人力成本的降低，對于企業來說通過平臺可以將人員分出梯次從而進一步的控制人力成本。對于個人來說通過對J-Hi開源平臺的學習(因為可以說平臺本身就是目前很多主流框架的一個容器)，可以快速的提升自己的技能，特別是在企業級開發上，從而自身價值的提升。

3）   管理成本，人員的流動尤其是核心人員的流動一直是企業面臨的棘手問題，而對應該問題的最好方式是在項目管理與開發上的標準化。J-Hi平臺為開發的標準化提供了一個基礎，原因在于代碼生成無論是代碼樣式、風格及配置文件的規則完全相同。這樣就保證無論人員如何流動這套標準是不會變化的。