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文件中引入該配置文件
iii. 如果您要對業務層的配置文件做修改，以appContext-text.xml為例，操作應該是1)新建一個appContext-test- customer.xml配置文件，2)在該文件中加入您自己的配置信息。注意新建的文件名必須以appContext開頭。
iv. 如果您要對權限配置文件做修改，以test-security.properties為例，操作應該是1)新建一個test-customer- security.properties配置文件，2)在該文件中加入您的配置信息。注意新建的文件名必須以-security結尾。***如果您想刪除生成的配置文件中某些配置項(即對某些url或方法不要求做權限控制)，推薦在整個項目做完后統一處理。
