上次說到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的訪問語法。比如以下的元數據：

對比Velocity要使用JDom的API，簡單了不知多少倍。就這點，讓Freemarker勝出，因為Code Generate的過程中，實在要訪問太多的xml元數據。也是這點，讓我在jsp和freemarker間模棱兩可。本來，因為生成的是代碼，不是頁面，freemarker markup-language化的優勢并不存在。而jsp的好處是人人都懂，而且有最好的IDE，擴展性還超強，可以做任意的事情。

不過，說到底， 用什么做模板，其實不是件很重要的事情，這里只是寫一下group memoring，記錄低決定的過程。進入討論組討論。