J-Hi的生成器到底生成了些什么?
自J-Hi正式發(fā)布以來(2011-1-14)已有三百多個(gè)愛好者加入我們的交流群，下載次數(shù)約1300次。隨著使用者的增加逐漸增多，大家在使用中的疑問也越來越多。其中最多的問題就是生成器到底生成了些什么東西，下面以xxx服務(wù)，實(shí)體***為例，對生成的文件一一講解：
數(shù)據(jù)庫相關(guān)
對應(yīng)不同的數(shù)據(jù)庫J-Hi會(huì)生成不同的數(shù)據(jù)庫腳本文件，生成的文件會(huì)臨時(shí)存放在web/db目錄下的相關(guān)數(shù)據(jù)庫(MSSQL/MYSQL/ORACLE)子目錄下，每次生成該目錄下的文件都會(huì)清理一次。生成的文件如下：
xxx.sql 定義該服務(wù)下所有實(shí)體(枚舉實(shí)體除外)的數(shù)據(jù)庫表的創(chuàng)建
xxx_BaseData.sql用于對該服務(wù)下的實(shí)體，為系統(tǒng)表插入相關(guān)數(shù)據(jù),系統(tǒng)表包括：菜單、權(quán)限、枚舉等，通過該文件會(huì)將與實(shí)體相關(guān)的菜單信息，權(quán)限信息等一次性的插入到系統(tǒng)表中
Java相關(guān)
因?yàn)镴ava含蓋的框架有很多，采用不同的框架不同的技術(shù)生成的內(nèi)容會(huì)有所不同，下面讓我們按三層結(jié)構(gòu)的原理劃分說明：
數(shù)據(jù)訪問層
xxx.dao包為數(shù)據(jù)訪問層的總包，對應(yīng)不同的ORM框架還會(huì)有相應(yīng)的子包，比如hibernate、ibatis(ibatis2)、ibatis3等子包。
***DAO.java：在dao包下這是個(gè)接口，用于規(guī)范不同框架之間的差異。
hibernate子包：
***DAOHibernate.java：hibernate數(shù)據(jù)訪問的具體實(shí)現(xiàn)類，該類繼承BaseDAOHibernate，從而實(shí)現(xiàn)對hibernate的封裝
***.hbm.xml：該文件是hibernate的映射文件
我們之所以把ibatis的兩個(gè)不同版本分兩個(gè)子包來管理，是因?yàn)閕batis2與ibatis3在底層實(shí)現(xiàn)上已經(jīng)有很大的差異，無論是內(nèi)部運(yùn)行原理還是配置文件基本上是顛覆性的變化。
ibatis子包
***DAOIbatis.java：ibatis2數(shù)據(jù)訪問的具實(shí)體現(xiàn)類，該類繼承BaseDAOIbatis，從而實(shí)現(xiàn)對Ibatis2的封裝
***.ism.xml：ibatis2的映射文件，之所以后綴叫ism是指ibatis sql mapping
ibatis3子包
***DAOIbatis3.java：ibatis3數(shù)據(jù)訪問的具實(shí)體現(xiàn)類，該類繼承BaseDAOIbatis，從而實(shí)現(xiàn)對Ibatis3的封裝
***.ism3.xml：ibatis3的映射文件，之所以后綴叫ism是指ibatis3 sql mapping
業(yè)務(wù)邏輯層
業(yè)務(wù)邏輯層J-Hi采用的是spring，因此大體上與spring的標(biāo)準(zhǔn)結(jié)構(gòu)完全相同
xxx.service包為業(yè)務(wù)邏輯層的總包，接口定義在該包下
***Manager.java：業(yè)務(wù)邏輯的接口類文件，缺省生成的是實(shí)體的增刪查改方法，如果在業(yè)務(wù)邏輯層中想做權(quán)限控制，可以調(diào)用*Security***()方法
xxx.service.impl包下的
***ManagerImpl.java：是業(yè)務(wù)邏輯的具體類，該類繼承ManagerImpl類。如果是特定的業(yè)務(wù)邏輯一定要在該類中通過手寫代碼的形式實(shí)現(xiàn)之
appContext-xxx.xml：是spring的配置文件，放在置在xxx包下
表現(xiàn)層
xxx.action包為表現(xiàn)層的總包，對應(yīng)不同的表現(xiàn)層框架會(huì)有相應(yīng)的子包，比如webwork、struts等子包。
***PageInfo.java：在action總包下，該類是與框架無關(guān)的，實(shí)際上該類記錄頁面信息的一個(gè)POJO，信息主要包括三部分：1)翻頁(page)：行數(shù)、當(dāng)前頁數(shù)等;2)過濾器(filter)：即查詢條件;3)排序器(sorter)：即正序倒序
webwork子包：
***ListAction.java：查詢頁面時(shí)所調(diào)用的動(dòng)作
***.RemoveActoin.java：刪除記錄時(shí)所調(diào)用的動(dòng)作
***.RemoveAllActoin.java：批量刪除時(shí)所調(diào)用的動(dòng)作
***SaveAction.java：保存記錄時(shí)所調(diào)用的動(dòng)作
***.ViewAllActoin.java：查看記錄時(shí)所調(diào)用的動(dòng)作
xwork-xxx.xml：webwork的配置文件
與webwork相比，struts的類文件只有一個(gè)，所以的動(dòng)作都是通過方法命名調(diào)用實(shí)現(xiàn)的，我們之所以做成兩種生成方式，是想考慮用戶會(huì)有個(gè)自不同的編程偏好，從而我們?yōu)樾┰诓煌蚣荛g提供兩種生成模式，以適應(yīng)這種編程偏好的差異
struts子包：
平臺(tái)目前舍棄了對struts1.x的支持，所以與struts相關(guān)都是以struts2為前提的
***Action.java：該Action包括了所有的頁面調(diào)用動(dòng)作，通過方法命名進(jìn)行調(diào)度
struts-xxx.xml：struts2的配置文件
POJO及其它
在xxx.model包為POJO的總包，一個(gè)POJO實(shí)際上是由兩個(gè)類文件組成的，即
***Abstract.java：該類是POJO的抽象類
***.java：該類是POJO的具體類
之所以這樣做是為了避免手寫的代碼會(huì)被生成器生成的文件所覆蓋
***.java：如果在定義是有枚舉實(shí)體，在model包下還有會(huì)生對應(yīng)枚舉實(shí)體的常量類文件
***-conversion.properties：如果實(shí)體有從實(shí)體，也就是主從結(jié)構(gòu)，生成器對應(yīng)主實(shí)體生成該文件，其目的是為了適應(yīng)表現(xiàn)層框架對頁面信息的對象化封裝
xxx--security.properties：該文件放置在xxx包下，是權(quán)限的映射信息的配置文件
頁面相關(guān)
以后生成器會(huì)根據(jù)所選模版不同，而對應(yīng)生成的頁面會(huì)有很大差異，現(xiàn)在以目前平臺(tái)的經(jīng)典模版為例
***List.jsp：查詢頁面
***Edit.jsp：編輯頁面
***View.jsp：查看頁面
***.js：與JSP文件應(yīng)對應(yīng)的javascript文件
源數(shù)據(jù)相關(guān)
***.hsc.xml 對應(yīng)每個(gè)服務(wù)，平臺(tái)在WEB-INF/matadate目錄下都會(huì)生成一個(gè)源數(shù)據(jù)的描述文件。該文件記錄了定義了模型的全部信息。hsc的意義為：hi service config
基于平臺(tái)生成器避免手動(dòng)代碼被覆蓋的解決方案
如果您采用本平臺(tái)開發(fā)，理論上80%以上的代碼都是生成出來的。這樣就帶來了一個(gè)新問題—如何保證我手動(dòng)改寫或添加的代碼不會(huì)被生成器生成的文件所覆蓋?
考慮到上述問題生成器在生成文件時(shí)有如下規(guī)則：
生成器會(huì)反復(fù)生成并覆蓋以下類與文件：
i. model.original包下的抽象類
ii. action包下***PageInfo類
iii. model包下的***.hbm.xml文件
iv. 服務(wù)根包下的appContext-***.xml文件
v. 服務(wù)根包下的***-security.properties文件
vi. src根下的xwork-***.xml文件
除上述文件外，生成器對生成其它文件時(shí)均會(huì)判斷是否以存在，如果存生就不再生成也不會(huì)覆蓋已生成或手動(dòng)修改類或配置文件的內(nèi)容
從反復(fù)生成的文件規(guī)則上可以看出，生成器只會(huì)反復(fù)生成：
1) 與實(shí)體屬性密切相關(guān)的類或配置文件如模型的抽象類與***PageInfo、***.hbm.xml，因?yàn)閷?shí)體中的屬性名稱或數(shù)量發(fā)生變化，生成器要適應(yīng)對實(shí)體屬性的變化
2) 與整個(gè)服務(wù)相關(guān)的配置文件如xwork-***.xml、appContext-***.xml等等，因?yàn)橐粋€(gè)服務(wù)下會(huì)有多個(gè)實(shí)體，生成器要適應(yīng)服務(wù)下實(shí)體數(shù)據(jù)庫的增減
3) 對于那些與實(shí)體相關(guān)并且不與服務(wù)或?qū)嶓w屬性相關(guān)的類生成器卻只會(huì)生成一次如dao、service、action下的所有類，以保證您手寫的代碼不會(huì)被生成器所覆蓋
在基于平臺(tái)開發(fā)時(shí)，因采用生成器生成所以可以使用如下解決方案來避免您手寫的代碼或配置不會(huì)被生成器所覆蓋
i. 如果您要對模型類實(shí)現(xiàn)某個(gè)接口或方法，請改寫model包下的具體類，該類只會(huì)生成一次，注意千萬不要修改original包下抽象中的內(nèi)容
ii. 如果您要對表現(xiàn)層的配置文件做修改，以xwork-test.xml為例，操作應(yīng)該是1)新建一個(gè)xwork-test-customer.xml配置文件，2)將您要修改或要增加的actoin寫在該文件中(即使action名與xwork-test.xml只的action名重復(fù)也沒有關(guān)系，系統(tǒng)會(huì)以您的action為***優(yōu)先級)，3)在xwork.xml文件中引入該配置文件
iii. 如果您要對業(yè)務(wù)層的配置文件做修改，以appContext-text.xml為例，操作應(yīng)該是1)新建一個(gè)appContext-test- customer.xml配置文件，2)在該文件中加入您自己的配置信息。注意新建的文件名必須以appContext開頭。
iv. 如果您要對權(quán)限配置文件做修改，以test-security.properties為例，操作應(yīng)該是1)新建一個(gè)test-customer- security.properties配置文件，2)在該文件中加入您的配置信息。注意新建的文件名必須以-security結(jié)尾。***如果您想刪除生成的配置文件中某些配置項(xiàng)(即對某些url或方法不要求做權(quán)限控制)，推薦在整個(gè)項(xiàng)目做完后統(tǒng)一處理。
