在上面兩篇分別說明瞭設計中較為簡單也是很關鍵的實踐點。 第一模塊劃分，它是根據每個模塊所承載的業務，進行劃分，是應用程式一個靜態的描述。 第二合理組合，它是是將每個模塊調動起來，共同實現業務，是一個準動態的說明。 今天主要說明真個應用程式中消息和數據，以及如何迴圈，是完全動態的。同時也簡單的提到各種 ...
在上面兩篇分別說明瞭設計中較為簡單也是很關鍵的實踐點。
第一模塊劃分，它是根據每個模塊所承載的業務，進行劃分，是應用程式一個靜態的描述。
第二合理組合，它是是將每個模塊調動起來，共同實現業務，是一個準動態的說明。
今天主要說明真個應用程式中消息和數據，以及如何迴圈，是完全動態的。同時也簡單的提到各種設計框架。是終結篇。
我們先拿下載這個業務來說。顯示用戶點擊了界面下載按鈕onClick，然後onClicK調用調度層的onStartDownLoadApp(Item), 而調度層又將指令業務單元模塊下載模塊。調用下載模塊的onStartDown(Item)。從這裡可以看出，消息是一層一層的向下傳遞去。此時下載模塊開始下載到數據，然後上報下載進度downLaodProgress(id, progress)，該方法傳遞了下載項信息（id）和進度信息（progress），並且調用到調度層的downLoadAppProgress（id，progress），調度層的該方法有經一部的調用onUpdateProgress. 從而實現從下載模塊到頁面的一個數據的傳遞。
註意從下載模塊向上報進度的時候，是非同步的，因為下載是非同步的，所以上報進度需要到主線程里，所以相對下載來說該消息是非同步的才能到主線程。
由上可見，
1 消息的一步步同時下發，而且必然經過調度層。
2 數據的上報也是一層一層上傳，而且必然經過調度層。
當然，還可以舉其他例子，這裡就不在舉例了。總體來說在設計的時候，務必要理清楚消息和數據是如何流動，才能完整的總結出業務模型並且切合到設計中。
設計模型中有MVC，MVP，MVVM。其中MVC有個特征就是不但C可以更新V而且M也可以更新V（圓形的消息流），那麼這樣設計過程中V不但要照顧到C還要照顧到M，而M同樣不但要照顧到C還要照顧到V。這樣顯然是體現了複雜度。但是在大型的web項目中是很常用的。而MVP和MVVM的特征是V只和P（或者VM）相互調用，不被M調用。M只和P（或者VM）相互調用，而和V沒有直接關係。因此在設計中，V和M不必相互照顧。
上面提到的都是比較成熟的設計模型，但是無論那種設計模型都追求的目標是“低耦合，高內聚”，各個模塊相互照應但是有各司其職。照應中需要做到很好的解耦。
設計中常常用的五視圖方法，該方法比較全面，即考慮的周圍的運行環境和關聯模塊，也從動態和靜態描述了程式內部的介面和聯動方式。我用這種方法做過兩次設計。還是很不錯。以上四篇是結合他的理論以及我的實踐一個簡單的總結。
突然想到還有一點沒有談到，就是業務的變化與不變的考慮。這個也是非常重要，設計中要充分的考慮到那些業務會發生變化，如何將變化鎖定在可控的範圍內。這就需要一層介面，通過介面來規範可變的業務實現，及無論業務如何變化，都必須遵守該介面的契約。
完了。
