自J-Hi正式發(fā)布以來（2011-1-14）已有三百多個(gè)愛好者加入我們的交流群，下載次數(shù)約1300次。隨著使用者的增加逐漸增多，大家在使用中的疑問也越來越多。其中最多的問題就是生成器到底生成了些什么東西，下面以xxx服務(wù)，實(shí)體***為例，對(duì)生成的文件一一講解：
數(shù)據(jù)庫相關(guān)
對(duì)應(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用于對(duì)該服務(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ù)訪問層的總包，對(duì)應(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)對(duì)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)對(duì)Ibatis2的封裝
***.ism.xml：ibatis2的映射文件，之所以后綴叫ism是指ibatis sql mapping
ibatis3子包
***DAOIbatis3.java：ibatis3數(shù)據(jù)訪問的具實(shí)體現(xiàn)類，該類繼承BaseDAOIbatis，從而實(shí)現(xiàn)對(duì)Ibatis3的封裝
***.ism3.xml：ibatis3的映射文件，之所以后綴叫ism是指ibatis3 sql mapping
springjdbc子包
***DAOSpringJDBC.java：springJDBC數(shù)據(jù)訪問的具實(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ù)邏輯一定要在該類中通過手寫代碼的形式實(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總包下，該類是與框架無關(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)目前舍棄了對(duì)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ì)生對(duì)應(yīng)枚舉實(shí)體的常量類文件
***-conversion.properties：如果實(shí)體有從實(shí)體，也就是主從結(jié)構(gòu)，生成器對(duì)應(yīng)主實(shí)體生成該文件，其目的是為了適應(yīng)表現(xiàn)層框架對(duì)頁面信息的對(duì)象化封裝
xxx--security.properties：該文件放置在xxx包下，是權(quán)限的映射信息的配置文件
頁面相關(guān)
以后生成器會(huì)根據(jù)所選模版不同，而對(duì)應(yīng)生成的頁面會(huì)有很大差異，現(xiàn)在以目前平臺(tái)的經(jīng)典模版為例
***List.jsp：查詢頁面
***Edit.jsp：編輯頁面
***View.jsp：查看頁面
***.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)開發(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文件
除上述文件外，生成器對(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ù)庫的增減
3） 對(duì)于那些與實(shí)體相關(guān)并且不與服務(wù)或?qū)嶓w屬性相關(guān)的類生成器卻只會(huì)生成一次如dao、service、action下的所有類，以保證您手寫的代碼不會(huì)被生成器所覆蓋
在基于平臺(tái)開發(fā)時(shí)，因采用生成器生成所以可以使用如下解決方案來避免您手寫的代碼或配置不會(huì)被生成器所覆蓋
i. 如果您要對(duì)模型類實(shí)現(xiàn)某個(gè)接口或方法，請(qǐng)改寫model包下的具體類，該類只會(huì)生成一次，注意千萬不要修改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ù)也沒有關(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開頭。
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)一處理。