代碼生成器的存在價值

多年前用ASP的時候，就聽說了有一種叫做代碼生成器的神奇的東西。隻需要指定資料庫連結，這個代碼生成器就能夠産生一個界面，然後選擇你需要進行生成的資料表，按一下按鈕，馬上基于這個表的增删改查界面以及對應的ASP程式代碼就生成出來，着實友善。當時的我對ASP已經輕車熟路，看了一眼這個工具後，心中評估了一下，然後使用了一把……看到這個工具生成的ASP程式源代碼，讓人确實有點接受不了——大小寫不區分，大段大段的備援代碼。雖然生成的代碼确實能夠完成特定的業務操作，但是維護性确實太差了。據說後來有一些優質的代碼生成器能夠生成更好的程式，但是确實是從那個時候開始，代碼生成器在我心裡成了垃圾代碼堆砌的代名詞。我情願自己編寫一行一行代碼也不願意用代碼生成器。

現在，當專注于某一個行業，某一種特定業務時，你會發現重複性是如此之大。——使用者管理在大多數地方都是類似的，隻是使用者相對的字段有些不一樣；使用者登入界面、登出界面可能也是一樣的，隻是把某些圖檔換一下而已；大部分的業務操作都是增删改查，對于這種操作不斷的采用同一種方式進行重複、還得小心出錯；權限管理界面看起來也沒什麼大的不同……也許我們早就煩了。架構在某種程度上保證了項目的品質，但并不能減少編碼量；某些架構甚至需要更多的編碼（以及學習時間）。例如，與Servlet+JSP方式相比，Struts除了JSP, 還需要編寫特定的Form, Action,并在struts-config.xml中加上幾行；Tapestry則需要編寫.page, .html, 對應的Page類，如果需要驗證還得編寫Delegate類；至于FreeMaker,Velocity之類界面工作量可能小了一些，但還得需要編寫自己的簡單架構用以實作MVC模式。Spring內建了這些表示層，看起來比較好……

上述解決方案的根本問題在于，架構隻是保證了項目的品質、可維護性，但是沒有減少編碼量。是以，代碼生成器的使用便是理所當然的了。這方面已經有先例了，最有效、最能夠顯示代碼生成的威力的，當屬xdoclet的ejb任務。我們知道，建立一個EJB需要同時建立其他四個無聊的接口，xdoclet在這方面将代碼生成的威力發揮到了極緻。另外，middlegen也能夠建立基于資料庫，使用Hibernate, Struts, EJB技術的Web應用程式，他能夠生成JSP, Hibernate映射檔案，Java類，EJB類等。middlegen應該是我見到的最完整的應用程式生成器的雛形，但是他還不足以具體，不足以縮短編碼時間。

我思考了幾天，在做OpenBUGZ和公司項目的過程中，想出了這種模型：

基礎架構：Spring, Hibernate, Tapestry

Spring，Hibernate的好處自不待言，前台沒有采用Struts或者WebWork，是因為前兩者在界面表示上不夠靈活，Struts需要配合Tiles才能實作靈活的布局，WebWork不太熟悉，不知道如何實作靈活的布局。然而在Tapestry中布局的問題幾乎不是問題。

應用技術：Ant, Xdoclet, FreeMaker, JUnit

用FreeMaker而不用Velocity是因為前者有更多的支援，而且從我的使用感覺來說，FreeMaker相對較強大。

開發步驟：

1 首先開發者（項目經理或者技術經理）根據需求對整個系統模組化，完成基本類圖，生成所有的業務模型類；

2 根據業務模型類編寫Hibernate映射檔案（用xdoclet可能不太友善，特别是業務模型類存在繼承關系時）；

3 （代碼生成）生成對應的DAO接口例如XXXDAO，用來對XXX對象進行增删改查 (如果采用Spring Hibernate Template，這一步可以省略)

4 （代碼生成）生成采用Hibernate的DAO實作

5 （代碼生成）生成業務邏輯層代碼XXXManager，用來調用DAO層實作各種業務邏輯操作；

6 （代碼生成）生成XXXManager對應的單元測試

7 （代碼生成）生成業務模型類的增删改查界面Html（通過模闆）

8 （代碼生成）生成界面對應的Tapestry所需要的.page檔案

9 （代碼生成）如果需要驗證，還需要生成需要的Delegate類

10 （代碼生成）生成對應的增删改查Page類

11 （代碼配置）在Spring的配置檔案中配置DAO的事務

12 （代碼配置）在Spring的配置檔案中配置XXXManager

13 配置資料庫連結，利用Hibernate的SchemaExport直接生成資料庫

14 生成整個項目的檔案結構，包括build.xml，如果需要，也可以生成JBuilder或者Eclipse項目

15 開發：對 XXXManager進行更改，對界面進行修飾。

從上面可以看到，整個項目工作量已經很低了;-) 這樣對業務分析人員的要求比較高，要求一次能夠分析全面徹底。項目中最後的工作隻剩下修改業務邏輯，修改修改頁面了。這就是代碼生成器的威力。