談談UI架構設計的演化

談談UI架構設計的演化

經典MVC

在1979年，經典MVC模式被提出。

在當時，人們一直試圖將純粹描述思惟中的對象與跟計算機環境打交道的代碼隔離開來，而Trygve Reenskaug在跟一些人的討論中，逐漸剝離出一系列的概念，最初是Thing、Model、View、Editor。後來通過討論定爲Model、View和Controller。做者自言「最難搞的就是給這些架構組件起名字」。

由於當時的軟件環境跟如今有很大不一樣，因此經典MVC中的概念很難被如今的工程師理解。好比經典MVC中說：「view永遠不該該知道用戶輸入，好比鼠標操做和按鍵。」對一個現代的軟件工程師來講，這聽上去至關難以想象：難道監聽事件不須要相似這樣的代碼嗎？

view.onclick = ......

可是想一想在70年代末，80年代初，咱們並無操做系統和消息循環，甚至鼠標的光標都須要咱們的UI系統來自行繪製，因此咱們面對的應該是相似下面的局面：

mouse.onclick = ......
mouse.onmove = ......

當鼠標點擊事件發生後，咱們須要經過view的信息將點擊事件派發到正確的view來處理。假如咱們面對的是鼠標、鍵盤驅動這樣的底層環境，咱們就須要必定的機制和系統來統一處理用戶輸入而且分配給正確的view或者model來處理。這樣也就不難理解爲何經典MVC中稱"controller是用戶和系統之間的連接"。

由於如今的多數環境和UI系統設計思路已經跟1979年徹底不一樣，因此現代一些喜愛生搬硬套的"MVC"實現者經常會認爲controller的輸入來自view，以致於畫出model、view、controller之間很奇葩的依賴關係：

咱們來看看Trygve Reenskaug本身畫的圖（這惡趣味的骷髏啊……）：

值得一提的是，其實MVC的論文中，還提到了"editor"這個概念。由於沒有出如今標題中，因此editor聲名不著。MVC論文中推薦controller想要根據輸入修改view時，從view中獲取一個叫作editor的臨時對象，它也是一種特殊的controller，它會完成對view和view相關的model的修改操做。

控件系統

MVC是一種很是有價值的架構思路，然而時代在變遷，隨着以windows係爲表明的WIMP（window、icon、menu、pointer）風格的應用逐漸成爲主流，人們發現，view和controller某些部件之間的局部性實際上強於controller內部的局部性。因而一種叫作控件（control）的預製組件開始出現了。

控件自己帶有必定的交互功能，從MVC的視角來看，它既包含view，又包含controller，而且它經過"屬性"，來把用戶輸入暴露給model。

controller的輸入分配功能，則被操做系統提供的各類機制取代：

• 指針系統：少數DOS時代過來的程序員應該記得，20年前的程序中的「鼠標箭頭」其實是由各個應用本身繪製的，以MVC的視角來看，這應當屬於一個"PointerView"的職責範疇。可是20世紀之後，這樣的工做基本由操做系統的底層UI系統來實現了。
• 文本系統：今天咱們幾乎不須要再去關心文本編輯、選中、拖拽等邏輯，對web程序員能夠嘗試本身用canvas寫一個文本編輯框來體驗一下上個時代程序員編寫程序的感覺。你會發現，選中、插入/覆蓋模式切換、換行、退格、雙擊、拖拽等邏輯異常複雜，經典MVC模式中一般使用TextView和TextEditor配合來完成這樣的工做，可是今天幾乎找不到須要咱們本身處理這些邏輯的場景。
• 焦點系統：焦點系統經過響應鼠標、tab鍵等消息來使得控件得到操做系統級惟一的焦點狀態，全部的鍵盤事件一般僅僅會由擁有焦點的控件來響應。在沒有焦點系統的時代，操做系統一般是單任務的，可是即便是單一應用，仍然要本身管理多個controller之間的優先權和覆蓋邏輯，焦點系統不但從技術上，也從交互設計的角度規範化了UI的輸入響應，而最妙的是，焦點系統是對視覺障礙人士友好的，如今頗多盲人用讀屏軟件都是強依賴焦點系統的。

因此時至今日，MVC，尤爲是其中controller的功能已經意義不大，如果在控件系統中，再令全部用戶輸入流經一個controller則可謂不三不四、本末倒置。MVVM的提出者，微軟架構師John Gossman曾言：「我傾向於認爲它(指controller)只是隱藏到後臺了，它仍然存在，可是咱們不須要像是1979年那樣考慮那麼多事情了」

MVP

1996年，Taligent公司的CTO，Mike Potel在一篇論文中提出Model-View-Presenter的概念。

在這個時期，主流的view的概念跟經典MVC中的那個「永遠不該該知道用戶輸入」的view有了很大的差異，它一般指本文中所述的控件，此時在Mike眼中，輸入已是由view得到的了：

Model-View-Presenter是在MVC的基礎上，進一步規定了Controller中的一些概念而成的：

對，因此，不論你按照Mike仍是Trygve的理解方式，MVP和MVC的依賴關係圖應該是一！模！一！樣！的！由於Mike的論文裏說了「we refer to this kind（指應用程序全局且使用interactor, command以及selection概念的） of controller as a presenter」。presenter它就是一種controller啊！

把依賴關係畫成這樣也是醉了啊！無論你信不信我反正是不信啊！

標記語言和MVVM

隨着20世紀初web的崛起，HTML跟JS這樣標記語言+程序語言的組合模式開始變得使人注目。逐漸推出的Flex、Sliverlight、QT、WPF、JSF、Cocoa等UI系統不約而同地選擇了標記語言來描述界面。

在這樣的架構中，view（或者說叫控件，不可是從依賴關係上跟程序的其餘部件解耦，並且從語言上跟其它部分隔離開來。

標記語言的好處是，它能夠由非專業的程序員產生，經過工具或者通過簡單培訓，一些設計師能夠直接產生用標記語言描述的UI。想要突破這個限制使得view跟其它部分異常耦合可能性也更低。

然而這樣的系統架構中，MVC和MVP模式已經不能很好地適用了。微軟架構師John Gossman在WPF的XAML模式推出的同時，提出了MVVM的概念。

WPF得MVVM正式說明了它的view的概念跟MVC中的view的概念的區別。這裏簡單畫了一下：

在MVVM模式中，數據綁定是最重要的概念，在MVC和MVP中的view和model的互相通信，被以雙向綁定的方式替代，這進一步把邏輯代碼變成了聲明模式。

結語

從經典MVC到MVVM，UI架構通過數次重大變遷，一些概念也在不斷變化，架構和底層環境互相影響、適配，我認爲時至今日，經典MVC已經再也不是UI架構的正常選項。

更糟糕的是，今天無數通過演繹的MVC實現（如backbone）和科普文，要麼是本來做者概念已經很混亂，摻雜私貨，要麼爲了適配現代的標記語言和控件模式，本身修改了經典MVC中的一些概念和耦合關係。實際上今天MVC已經無法做爲一種交流的標準詞彙了。

寫此文，但願你們能瞭解些歷史上的發展歷程，莫被不嚴謹的文章誤導。其實本文的至關多觀點也是通過演繹的，因此我附上全部原始文獻連接，但願你們看了之後能有本身的判斷：）也歡迎你們據此指出我理解的錯誤之處。

參考資料

• MVC論文
• MVC論文翻譯
• MVP論文
• MVVM博文
• MVVM博文翻譯