上次說到MyAppfuse要有一個代碼生成工具， codegeneration.Net上匯集了各種平台各種語言的工具。 其實代碼生成是和代碼重復的bad smell一樣古老的東西了，不過在這個時代裡，大家充分發掘了繼承，委托，反射，甚至AOP的之後，coding 依然boring，依然重復，這時候就需要從一個更抽象的層次去描述系統，然後再生成我們又愛又恨的代碼，這就是產生式編程(GP)。
高階的MDA應用 那些用UML作元模型，配合MOF,OCL等等定義與轉換語法，期望能比較完整的描述系統的高階MDA應用，我想不會這麼快大范圍推廣，大家洗腳上田不用再Coding的機會不大。 一來，OMG的結構不像個很高產的組織。它目前的成果也比較高深。 二來，是底層技術的制約。因為MDA是由模型、實現和轉換程序三者構成的，如果模型定義飛速發展了，與底層實現之間必定會形成巨大落差，需要轉換程序做大量工作來消彌。當落差足夠大時，就會很少人願意做這個轉換工作。而為了減少落差： 一是等底層實現的發展，但這是整個IT界的事情，不是MDA開發者的個人問題。 二就唯有減低模型定義的高度，比如AndroMDA，很多現成的模板都只依賴於UML靜態Class圖。 但隨著AOP，Meta-Data，O/R Mapping，IOC Container這些底層的發展，還有微軟DSL對UML的沖擊，MDA還是會繼續慢慢發展，畢竟這是我們的夢。
輕型的代碼生成方案 當下還是挑些輕量級的代碼生成方案比較實際。我挑的是XML格式的自定義模型 + groovy template式的模板語言(注意，是groovy template，不是groovy)。 1.XML模型 現在OMG也松口了，UML不是唯一的方案，都可以通過更高一層的模型來描述與轉換。那XML對輕型建模無疑是最輕省了。 2.生成方案 當然也可以像Appfuse那樣用XDoclet，但我覺得XDoclet的擴展性，管理性和適用范圍都是最低的。也可以不用模板，用C#/Java程序完全控制代碼的生成，這種方式現在又多了Python,Ruby,Groovy這些動態語言可選擇。但我還是習慣模板多一些。
模版的選擇現在有JSp, velocity/freemarker和最新的groovy template。 這次把選擇的戰場從Web表現層移到輕量級代碼生成的模板，標准就有了變化。 一是重新要求模板代碼的靈活性，擴展性。因為輕量級代碼生成不會搞MVC，也不一定能很好的MVC，所以要求模板代碼本身能處理比較復雜的邏輯。所以JSP和Groovy template這種script型的比較占優，幾乎可以做任何事情。
二是要求內置的XML DOM語法。因為我們的元數據是定義在XML裡的，在Code Generatate的過程中要訪問太多XML，簡潔直觀的語法非常受用，無論是模板的可讀性還是書寫的速度，比如以下的元數據：
Freemarker或者Groovy Template可以這樣列出table下所有column的name：
<#list table.* as column> ${column.@name}
而JSP和Velocity就要用長長的jdom語法，把模板弄得很髒。
三是因為生成的是代碼，不是頁面，不是美工，freemarker/velocity markup-language化的優勢並不存在。
四是哪裡都需要的代碼簡潔，JSP是最不簡潔的。
可見，JSP比velocity/freemarker處理邏輯的能力強，Java語法人人都會；而velocity/freemarker比JSP簡潔，不需要依賴web container，freemarker還有內置的XML語法。 而Groovy Template，恰恰是兩者優點的結合，很難讓人再選其他。當然它目前還未成熟。 說到底， 用什麼做模板，其實不是件很重要的事情，在模版間遷移也不算困難，這裡只是寫一下group memoring，記錄低決定的過程。
