MDSF：代碼產生 VS 模型解釋

文章目錄

• 代碼產生相對於模型解釋的好處
• 模型解釋相對於代碼產生的好處
• 採用哪種方法
• 參考

　　在代碼產生（Code Generation）介紹中說到模型可以通過代碼產生技術和模型解釋兩種方法在領域架構運行，本篇主要介紹一下這兩種方法的利弊。

樣本

• 對於UI介面，我們基於模型驅動開發可以採用代碼產生和模型解釋來產生運行程式。

1. 代碼產生：通過模型，直接產生表單類，產生的表單類與傳統手工寫的代碼類似
2. 模型解釋：在OpenExpressApp中採用的AutoUI是採用模型解釋方法，我們通過給系統預定義一些表單模板，每類模板對應一個表單模板類，具體表單由模板讀模數型中繼資料來自動產生介面。剛發現有一個UI自動產生的項Metawidget，它使用的就是模型解釋，有時間好好看看。

• 對於實體類的設計：

1. 代碼產生：產生具體類
2. 模型解釋：解譯器產生一個Entity，Name為實體類名稱；這個Entity樣本下添加多個屬性，屬性名稱為實體屬性名稱

代碼產生相對於模型解釋的好處

• 保護你的智慧財產權：在產品線工程應用中，使用代碼產生只需要給特定使用者產生後的代碼，而使用模型解釋時，你需要把完整的解釋引擎以及模型都給客戶。
• 適用於客戶架構：模型解釋必須實現一個特定於自己架構的解譯器，而代碼產生可以依據客戶指導來產生客戶需要的代碼
• 產生後的實現代碼更容易理解：可以通過直接查看產生後的代碼來瞭解應用程式的行為，而採用模型解釋需要明白解譯器的通用實現以及模型的語義表達
• 容易開始：如果你已經應用過傳統方法構建過一個應用程式，那麼可以容易的使用代碼產生技術把現在的代碼轉為模板或者替代部分代碼。如果你構建了多個相同領域的應用程式，則可以通過分析這些系統的差異，可以把共性問題通過靜態代碼放在領域架構中，可變代碼通過代碼產生技術來產生。
• 更容易迭代：上面指出代碼產生可以把現有代碼使用代碼產生技術來產生，我們可以方便的先產生一部分代碼，之後再擴充產生其他代碼
• 方便利用編譯器來進行代碼檢查：產生代碼可以通過編譯器來檢查代碼錯誤，而模型解釋必須自己寫一個模型檢查器
• 調試產生代碼比調試解譯器更為容易：但是作為使用者，並不太需要調試解譯器
• 更容易跟蹤模板的更改： 代碼產生模板是文字檔，所以通過一些版本控制軟體可以很好的進行跟蹤，而模型解釋代碼由於通用性，它的改變會比模板變更追蹤複雜些。

模型解釋相對於代碼產生的好處

• 適應更快的變化：模型改變不需要額外的重建、構建、測試和部署過程，這能明顯的縮短總體時間。
• 支援運行期變化：可以通過運行期更改模型來更改應用，而不需要關閉應用程式。
• 更容易部署和運行：代碼產生需要使用語言平台進行編譯產生目標應用，而使用模型解釋不再需要代碼，只需要把模型放入模型解譯器中即可，因此它可以更容易的讓領域專家部署和運行應用，而不只是建模而已。
• 容易更新：很容易更改解譯器並重新運行同一個模型，不需要使用更新的產生器再次產生代碼。
• 比代碼產生更靈活：基於代碼產生的模板會有一些限制，而模型解譯器可以更靈活的處理。
• 運行期調試模型：模型可以在運行時進行調試，例如像系統工作流程一樣可以在某個活動中設定斷點，這在複雜流程和狀態模型中很有用。

採用哪種方法

　　從上面描述來看，代碼產生和模型解釋兩種模型到應用的轉換方法各有利弊，並沒有一種決定性的論斷來告訴你應該選擇哪一種方法，這個可能每個人的經驗、喜好、以及問題領域都有關係。

　　如果業務複雜，我希望在應用中有相應的類庫，這樣可以使用OO來編寫業務代碼，所以我個人偏向於類庫產生使用代碼產生技術。而介面產生相對來說具有一定的通用性，所以可以使用通用語言在領域架構中建立一些UI模板，通過模型解釋來自動產生代碼，這也是OpenExpressApp現在的解決方案。

　　如果你也關注MDD，瞭解代碼產生和模型解釋，你有什麼想法呢？

參考

Model Driven Development: Code Generation or Model Interpretation?

Model interpretation vs. code generation? Both.

Executable models vs code-generation vs model interpretation

代碼產生（Code Generation）介紹

 

歡迎轉載，轉載請註明：轉載自周金根 [ http://zhoujg.cnblogs.com/ ]