現(xiàn)代大型客戶端軟件，考慮到各種終端類型(Windows, Mac, ios, Android...)，大部分采用分層設(shè)計(jì)，用C++封裝跨平臺的SDK/Framework, UI層采用各平臺Native語言實(shí)現(xiàn)(C++/Java/objective-c)，典型的分層如下：
最近工作要對UI層進(jìn)行重構(gòu)，對UI層的設(shè)計(jì)進(jìn)行了一些思考，UI層是客戶端直接和用戶交互的那層，它的好壞直接影響到整個(gè) 產(chǎn)品的用戶體驗(yàn)， 重要性不言而喻。但是很多時(shí)候我們卻很難將這層代碼寫好，給用戶良好的用戶體驗(yàn), 主要下面一些因素：
(1)邏輯復(fù)雜性， 因?yàn)檫@層是整個(gè)客戶端所有feature的最終集成地
(2)各種屏幕尺寸的適配，這個(gè)Mobile上更明顯
(3)Accessibility的支持: tab導(dǎo)航，高對比，高DPI， 讀屏...
(4) 換膚和多語言
上面問題(2)(3)(4)都是和具體平臺系統(tǒng)相關(guān)的，這里我們重點(diǎn)關(guān)注如何解決問題(1), 也就是如何通過合理的設(shè)計(jì)降低UI層的復(fù)雜性, 因?yàn)閁I層的代碼往往寫到最后變成了"一坨屎"。
其實(shí)UI層的設(shè)計(jì)已經(jīng)有很多成熟的模式，我們依次看下：
(1) Original MVC
這是最早的的MVC模式， 據(jù)說最早的計(jì)算機(jī)鼠標(biāo)鍵盤不是直接關(guān)聯(lián)在view上的， 因此它們的輸入事件會(huì)先到達(dá)contorller端， 然后由controller去修改model， model再通知view更新數(shù)據(jù)(view更新時(shí)會(huì)從Model取數(shù)據(jù))
(2) Modern MVC
這是現(xiàn)在大家對MVC模式的理解，和上面的original MVC類似， 只不過鼠標(biāo)鍵盤事件的輸入源轉(zhuǎn)成了View, 這也符合大家對窗口理解
(3) MVP
MVP模式割斷了Model和View端的直接通訊，讓Controller(Presenter)當(dāng)作中介者，View接收到鼠標(biāo)鍵盤事件后通過event通知controller, controller把新數(shù)據(jù)更新到model, model數(shù)據(jù)更改后通知訂閱它事件的controller, controller再把新數(shù)據(jù)更新到view端
(4) Dialog MVP
這種方式是簡化版的MVP， 把View和Controller寫在一個(gè)dialog里面，雖然UI和邏輯寫在了一起，但是使用起來很簡單。
(5) MVVM
MVVM (Model-View-ViewModel) 是MVP的改進(jìn)，它講Presenter改成了支持?jǐn)?shù)據(jù)綁定的ViewModel， 這是WPF特有的一種數(shù)據(jù)模型，依賴語言和庫對數(shù)據(jù)綁定的支持。
通過觀察，我們發(fā)現(xiàn)上面無論那種模型，都有幾個(gè)基本概念：
a. View， 展示界面
b. Controller, 控制邏輯
c. Model, 廣域的model指的是領(lǐng)域建模的業(yè)務(wù)模型層，因?yàn)槲覀冞@里已經(jīng)將業(yè)務(wù)模型封裝在了Framework(SDK)及其下層， 所以我們這里的model主要指的是UI層的一些數(shù)據(jù)模型。
我們發(fā)現(xiàn)每個(gè)view都有一個(gè)controller來控制它， 但是很多時(shí)候一個(gè)feature我們需要協(xié)調(diào)多個(gè)controller/view， 比如IM里收到一條消息， 你可能既要在消息窗口中顯示， 同時(shí)也要在右下角像QQ那樣出個(gè)提示， 另外可能還需要播放提示音， 這么多事情需要有人來協(xié)調(diào)， 所以我們需要引入Manager的概念， Manager以feature/模塊為劃分單位。
另外有些view可能會(huì)很復(fù)雜， 所以需要引入sub-view的概念， 也就是說一個(gè)復(fù)雜的view可能是一顆樹， 它由很多sub-view和， 甚至grandchild-view組成， 同時(shí)每個(gè)view/child-view/grandchild-view都有自己的controller來處理它的事件。
另外一個(gè)view是由多個(gè)控件元素(Element Control)組成，很多時(shí)候我們需要對控件元素進(jìn)行定制， 我想這是大家知道的一個(gè)常識。
UI層基本的結(jié)構(gòu)大概如下：
另外有些時(shí)候我們需要在Manager, Controller和Data Model之間進(jìn)行一些事件廣播， 因此我們需要引入消息中心(message center)的概念。
這樣最終的層次結(jié)構(gòu)圖大概類似這樣：
我們看下各層的訪問規(guī)則：
UI Eelement Control, 是界面的基本組成元素, 它的事件會(huì)通知到自己的view (Windows/Panel)；
UI View, 可以完全控制自己的Element control, 它收到控件事件后會(huì)通知到自己的 UI Controller；
UI Controller, 可以完全控制自己的UI View， 并且響應(yīng)UI View的事件消息， UI Controller可以調(diào)用自己的UI Data model存儲數(shù)據(jù)， 也可以調(diào)用某個(gè)UI Manager的接口處理事件；
UI Manager， 和底層Framework/SDK打交道，可以完全控制controller， 也可以通過message center廣播重大事件；
我們可以看到， Manager->Controller->View->Eelement, 我們逐層都是基于類完全訪問， 反之則是基于接口事件消息， 這也符合設(shè)計(jì)中的單向依賴原則。
另外我們再說下UI Data Model的設(shè)計(jì)， UI Data Model實(shí)際上分成public和private兩種類型， 其中public的數(shù)據(jù)是共享的， 可能是多個(gè)controller/manager都要訪問的， private則是某個(gè)controller私有的數(shù)據(jù)。
這樣整個(gè)UI層的層次結(jié)構(gòu)就很清楚了：
首先有個(gè)總的UI Manager， 它下面包含三種角色： UI Manager Manager, UI Controller Manager, UI Data Manager。
（1）UI Manager Manager根據(jù)feature/模塊分成多個(gè)子UI Manager， 子UI Manager根據(jù)需要也可以包含自己的子UI Manager；
（2）UI Controller Manager根據(jù)窗口數(shù)量管理多個(gè)窗口的UI Controller， 其中復(fù)雜窗口的UI Controller可能包含樹狀的子UI Controller；
（3）UI Data Manager根據(jù)數(shù)據(jù)類型，管理多個(gè)public/Share 的UI Data Model； private的UI Data Model是每個(gè)Controller私有的，外面沒法直接訪問，由它的controller暴露接口訪問。
另外對于復(fù)雜的UI， 我們可能還需要引入U(xiǎn)I Layout Manager的角色， 因?yàn)閺?fù)雜UI在不同的情況下整個(gè)UI layout會(huì)有巨大改變， 比如會(huì)議系統(tǒng)中共享桌面時(shí)你可能需要把整個(gè)主窗口隱藏，在單屏和雙屏?xí)r整個(gè)UI又完全不一樣， 所以我們需要借助UI Layout Manager協(xié)調(diào)多個(gè)窗口的顯示和隱藏。
最后我們總結(jié)下上面這種架構(gòu)設(shè)計(jì)的優(yōu)勢：
(1) 界面和邏輯的分離， view和controller可以由不同的人分別實(shí)現(xiàn)， 獨(dú)立變動(dòng)
(2) 基于接口分層設(shè)計(jì)， 單向依賴且低耦合
(3) UI層數(shù)據(jù)類型的分類，共有共享的還是私有的
(4) 消息中心，同時(shí)支持同步/異步的消息廣播機(jī)制， Manager/Controller/Data Model可以各自訂閱自己感興趣的消息
(5)每個(gè)Manager主要關(guān)注自己的那塊feature， 單一職責(zé)