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