上次說到MyAppfuse要有一個代碼生成工具， codegeneration.net上匯集了 各種平台各種語言的工具。
其中一些用到UML做元數據的，就變成了上年最流行的MDA tool。MDA其實是 超級炒冷飯了，偶N年前的畢業論文做的就是這個題目，現在再看進步也不大。
不過想下也正常。因為MDA是由模型、實現和轉換程序三者構成的，如果模型 定義飛速發展了，與底層實現之間必定會形成巨大落差，需要轉換程序做大量工 作來消彌。當落差足夠大時，就會很少人願意做這個轉換工作。而為了減少落差 ，一是等底層實現的發展，但這是整個IT界的事情，不是MDA開發者的個人問題 。另外就唯有減低模型定義的高度，比如AndroMDA，很多現成的模板都只依賴於 UML靜態Class圖，同時使用大量的Tagged Value，看上去和一個xml格式的自定 義模型沒什麼區別。
所以，一來受底層實現的制約，二來OMG的結構也不像個很高產的組織，MDA 忽然爆發，大家洗腳上田不用再Coding的機會不大。但隨著AOP,Meta-Data,O/R Mapping,IOC Container這些底層的發展，還有微軟DSL對UML的沖擊，MDA還是會 繼續慢慢發展，畢竟這是我們的夢。
當下還是挑些輕量級的代碼生成方案比較實際。我挑的是XML格式的自定義模 型 + jsp/Freemarker模板。當然也可以像Appfuse那樣用XDoclet，但我覺得 XDoclet的擴展性，管理性和適用范圍都是最低的。也可以不用模板，用C#/Java 程序完全控制代碼的生成，這種方式現在又多了Python,Ruby這些動態語言可供 選擇。
但我還是習慣模板多一些。比如jsp，可以用Httpclient訪問jsp，獲得返回 內容來生成文件。而xml格式的元數據， 可以通過Filter放入到Request或者 Session中。
不過，現在流行Velocity和Freemarker。兩者之間可以用三局兩勝制決出。
一，Freemarker網站上有一篇文章，列出了Freemarker語法上比Velocity優 勝的地方。
二，但現在的PM不能夠這麼狹隘的從純技術角度看問題的了，Velocity有著 比Freemarker多得多的用戶群體，比如AndroMDA, IntelliJ IDEA。
三，又但是，對於這種用XML格式定義的元數據，Freemarker有一個很少被提 到，但無匹的優勢--內置了XML DOM的訪問語法。比如以下的元數據：
<table>
<column name="id"/>
<column name="name"/>
</table>
Freemarker可以這樣列出table下所有column的name：
<#list table.* as column>
${column.@name}
對比Velocity要使用JDom的API，簡單了不知多少倍。就這點，讓Freemarker 勝出，因為Code Generate的過程中，實在要訪問太多的xml元數據。也是這點， 讓我在jsp和freemarker間模稜兩可。本來，因為生成的是代碼，不是頁面， freemarker markup-language化的優勢並不存在。而jsp的好處是人人都懂，而 且有最好的IDE，擴展性還超強，可以做任意的事情。
不過，說到底， 用什麼做模板，其實不是件很重要的事情，這裡只是寫一下 group memoring，記錄低決定的過程。
