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