第3版--2005.6.22更新
上次說到MyAppfuse要有一個代碼生成工具, codegeneration.net上彙集了各種平台各種語言的工具。
其實代碼生成是和代碼重複的bad smell一樣古老的東西了,不過在這個時代裡,大家充分發掘了繼承,委托,反射,甚至AOP的之後,coding 依然boring,依然重複,這時候就需要從一個更抽象的層次去描述系統,然後再生成我們又愛又恨的代碼,這就是産生式程式設計(GP)。
高階的MDA應用
那些用OMG 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對輕型模組化無疑是最輕省了。在Martin Fowler也認為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,簡潔直覺的文法非常受用,無論是模闆的可讀性還是書寫的速度,比如以下的中繼資料:
<table>
<column name="id"/>
<column name="name"/>
</table>
Freemarker或者Groovy Template可以這樣列出table下所有column的name:
<#list table.* as column>
${[email protected]}
</#list>
而jsp和Velocity就要用長長的jdom文法,把模闆弄得很髒。
三是因為生成的是代碼,不是頁面,不是美工,freemarker/velocity markup-language化的優勢并不存在。
四是哪裡都需要的代碼簡潔,jsp是最不簡潔的,而Groovy作為新一代動态語言則比較迷人。
五是IDE,freemarker, velocity, groovy template一個比一個寒酸
可見,jsp比velocity/freemarker處理邏輯的能力強,java文法人人都會;
而velocity/freemarker比jsp簡潔,不需要依賴web container,freemarker還有内置的xml文法。
而Groovy Template,恰恰是兩者優點的結合。當然它目前還未成熟,也沒有好的IDE。
so,團隊裡Groovy Template 或 Freemarker都是可行的選擇。
說到底, 用什麼做模闆,其實不是件很重要的事情,在模版間遷移也不算困難,這裡隻是寫一下group memoring,記錄低決定的過程。
相關文章: 用Groovy Template 生成代碼 2nd