? 對于目前MDA(Model Driven Architecture)的理論和實現(xiàn),我一直持一種消極態(tài)度。以前和hotman_x的討論中，我也明確表述過對于MDA的看法。
? MDA：以有限搏無限
http://canonical.blogdriver.com/canonical/787637.html? 圖形 vs. 文本
http://canonical.blogdriver.com/canonical/1090209.html? 所謂的MDA一般總是從高層抽象模型出發(fā)，希望通過預定的建模過程推導出底層的全部實現(xiàn)細節(jié)。但是implementation is also interpretation. 實現(xiàn)過程本身也是對高層模型的一種詮釋過程, 是一個逐步明晰并逐漸消除概念之間矛盾沖突的過程。從高層模型到底層實現(xiàn)并不是一個同構(isomorphism)的過程，甚至一般情況下也不是同態(tài)(homomorphism)的。在概念模型到具體代碼實現(xiàn)的過程中，總是存在著需要不斷補充的細節(jié)。這些細節(jié)如何才能成為高層模型的一種自然的衍生部分是一個非常復雜的問題。如果考慮得太細（需要指定過多難以從整體上進行控制的參數(shù)），似乎就會喪失高層模型的抽象性和概括性，而如果不深入到細節(jié)，則難以平衡高層模型之間的互相沖突的屬性。隨著細節(jié)的不斷增加，試圖維持高層模型在各個層面的統(tǒng)一性無疑將變得異常困難。實際上在每一個抽象層面概念都可能出現(xiàn)重組和混合的情況，試圖統(tǒng)一建模在目前的技術水平下是不太現(xiàn)實的。
? MDA所需要解決的一個核心問題是維護模型的持續(xù)有效性, 即當根據(jù)模型構造出實際系統(tǒng)之后, 對模型的修改仍可以自動反映到已實現(xiàn)的系統(tǒng)中, 而不是每次重新生成一個新的系統(tǒng). 或者說MDA應當如何支持實現(xiàn)層面的重構. 為了解決這個問題, 一般的實現(xiàn)策略是建立完整的程序模型, 提供一個強大的集成開發(fā)工具, 可以在一個特意構造出的IDE環(huán)境中對模型進行調(diào)試, 修正, 盡量避免程序員直接接觸實現(xiàn)代碼, 確保一切細節(jié)盡在單一開發(fā)工具(單一信息驅(qū)動源)的掌握之中. 但是很顯然, 這樣一個大一統(tǒng)的開發(fā)工具在各個層面(如數(shù)據(jù)庫設計, 表單設計等)都只能是專業(yè)工具的一個簡化版. too simple, sometimes naive. 當我們需要對程序有較深入的控制力的時候, 這些工具往往就很難起什么作用了, 甚至會成為某種障礙.
? 在witrix平臺的設計中, 也有部分"MDA"的內(nèi)容. 只是我們的設計思想是Physical Model Driven(物理模型驅(qū)動), 而不是Logical Model Driven(邏輯模型驅(qū)動). 具體做法是
1. 采用power designer建立數(shù)據(jù)庫物理模型(PDM 而不是 CDM), 然后根據(jù)一些命名約定和附加注釋(例如pdm中的package映射為java實體類的package, pdm的domain指定字段是否附件字段等)來標注出物理元素的邏輯含義.
2. 解析pdm文件, 生成hibernate映射文件(.hbm.xml), meta文件(.meta.xml), spring注冊文件(.action.xml)等
3. 通過jboss的hibernate-tools工具生成java實體類.
???
? 根據(jù)自動生成的配置文件, 可以直接完成對于數(shù)據(jù)庫的增刪改查操作, 包括維護一對多,多對多等關聯(lián)關系. 此后我們可以根據(jù)程序具體需求, 對生成的文件進行修改. 通過一些程序設計技巧, 我們可以實現(xiàn)手工修改的代碼與工具自動生成的代碼之間始終有明確的邊界, 從而可以做到pdm與代碼的自動同步, 不需要手工進行任何調(diào)整.
? 我們選擇從PDM出發(fā)的一個基本理由在于, 從高層模型向下, 路徑是不確定的，而從物理模型向上，路徑是確定的. 在pdm中我們需要做的不是補充細節(jié)(增加新息)而是標注出已經(jīng)存在的邏輯概念。選擇PDM建模也集中體現(xiàn)了我所一直倡導的Partial Model的概念. PDM模型并不包含界面的具體展現(xiàn)方式, 也不包含更加復雜的業(yè)務處理過程, 它只是完整程序模型的一部分. 我們不試圖建立一種完全的模型，追求概念上的一種自我完備性, 而只是關注當某些被共享的模型元素發(fā)生變化的時候, 這些變化如何以保真的方式傳播到系統(tǒng)各個角落. 實際上一旦獲得物理實現(xiàn)，高層模型在某種意義上就變得不再那么重要了. 為了支持模型的局部修改, 我們只需要從物理模型中提取部分信息，而不需要恢復出一個完整的業(yè)務模型。我們不需要把一個高層概念在各個層面的表達都考慮清楚，我們只需要知道某一特定的物理模型應該對應的部分高層模型即可。
? 目前國內(nèi)一些軟件開發(fā)平臺也包含所謂MDA的部分, 例如浪潮Loushang MDA (
www.loushang.com)號稱不需要寫一行代碼，定制出所需應用系統(tǒng). 可從其技術白皮書來看, 它所謂的Model雖然是使用UML來建立, 但是大家似乎故意忘記了對象是成員變量+行為構成，不包含行為模型的對象模型不過是數(shù)據(jù)模型的一種翻版而已. 從Loushang MDA的元模型對象的UML圖可以看出, MofTab, MofReference等固定了幾種界面顯示模式, 似乎其MDA只是針對既定場景應用的一種預制代碼框架. 從我們的實踐來說, 數(shù)據(jù)模型驅(qū)動的應用并不需要限制在基礎數(shù)據(jù)對象維護這一非常特定的領域，而可以在通用應用領域發(fā)揮作用。