|
【編者按】近日，阿里無線事業(yè)部前端工程師寒泉在一篇文章《談?wù)刄I架構(gòu)設(shè)計(jì)的演化》中表示，從經(jīng)典MVC到MVVM，UI架構(gòu)經(jīng)過數(shù)次重大變遷。今天無數(shù)經(jīng)過演繹的MVC實(shí)現(xiàn)和科普文，要么是原本作者概念已經(jīng)很混亂，摻雜私貨，要么為了適配現(xiàn)代的標(biāo)記語言和控件模式，自己修改了經(jīng)典MVC中的一些概念和耦合關(guān)系。實(shí)際上今天MVC已經(jīng)沒法作為一種交流的標(biāo)準(zhǔn)詞匯了。該文從MVC的發(fā)展歷程著手，對其概念及演進(jìn)過程進(jìn)行了肅清，以防開發(fā)者被誤導(dǎo)。下面為原文。 經(jīng)典MVC 在1979年，經(jīng)典MVC模式被提出。 在當(dāng)時，人們一直試圖將純粹描述思維中的對象與跟計(jì)算機(jī)環(huán)境打交道的代碼隔離開來，而Trygve Reenskaug在跟一些人的討論中，逐漸剝離出一系列的概念，最初是Thing、Model、View、Editor。后來經(jīng)過討論定為Model、View和Controller。作者自言“最難搞的就是給這些架構(gòu)組件起名字”。 因?yàn)楫?dāng)時的軟件環(huán)境跟現(xiàn)在有很大不同，所以經(jīng)典MVC中的概念很難被現(xiàn)在的工程師理解。比如經(jīng)典MVC中說：“View永遠(yuǎn)不應(yīng)該知道用戶輸入，比如鼠標(biāo)操作和按鍵。”對一個現(xiàn)代的軟件工程師來說，這聽上去相當(dāng)不可思議：難道監(jiān)聽事件不需要類似這樣的代碼嗎？ view.onclick = ...... 但是想想在70年代末，80年代初，我們并沒有操作系統(tǒng)和消息循環(huán)，甚至鼠標(biāo)的光標(biāo)都需要我們的UI系統(tǒng)來自行繪制，所以我們面對的應(yīng)該是類似下面的局面： mouse.onclick = ......mouse.onmove = ...... 當(dāng)鼠標(biāo)點(diǎn)擊事件發(fā)生后，我們需要通過View的信息將點(diǎn)擊事件派發(fā)到正確的View來處理。假如我們面對的是鼠標(biāo)、鍵盤驅(qū)動這樣的底層環(huán)境，我們就需要一定的機(jī)制和系統(tǒng)來統(tǒng)一處理用戶輸入并且分配給正確的View或者M(jìn)odel來處理。這樣也就不難理解為什么經(jīng)典MVC中稱"Controller是用戶和系統(tǒng)之間的鏈接"。 因?yàn)楝F(xiàn)在的多數(shù)環(huán)境和UI系統(tǒng)設(shè)計(jì)思路已經(jīng)跟1979年完全不同，所以現(xiàn)代一些喜好生搬硬套的"MVC"實(shí)現(xiàn)者常常會認(rèn)為Controller的輸入來自View，以至于畫出Model、View、Controller之間很奇葩的依賴關(guān)系： 我們來看看Trygve Reenskaug自己畫的圖（這惡趣味的骷髏啊……）： 值得一提的是，其實(shí)MVC的論文中，還提到了"editor"這個概念。因?yàn)闆]有出現(xiàn)在標(biāo)題中，所以editor聲名不著。MVC論文中推薦Controller想要根據(jù)輸入修改View時，從View中獲取一個叫做editor的臨時對象，它也是一種特殊的Controller，它會完成對View和View相關(guān)的Model的修改操作。 控件系統(tǒng) MVC是一種非常有價值的架構(gòu)思路，然而時代在變遷，隨著以windows系為代表的WIMP（window、icon、menu、pointer）風(fēng)格的應(yīng)用逐漸成為主流，人們發(fā)現(xiàn)，View和Controller某些部件之間的局部性實(shí)際上強(qiáng)于Controller內(nèi)部的局部性。于是一種叫做控件（control）的預(yù)制組件開始出現(xiàn)了。 控件本身帶有一定的交互功能，從MVC的視角來看，它既包含View，又包含Controller，并且它通過"屬性"，來把用戶輸入暴露給Model。 Controller的輸入分配功能，則被操作系統(tǒng)提供的各種機(jī)制取代：
所以時至今日，MVC，尤其是其中Controller的功能已經(jīng)意義不大，若是在控件系統(tǒng)中，再令所有用戶輸入流經(jīng)一個Controller則可謂不倫不類、本末倒置。MVVM的提出者，微軟架構(gòu)師John Gossman曾言：“我傾向于認(rèn)為它(指Controller)只是隱藏到后臺了，它仍然存在，但是我們不需要像是1979年那樣考慮那么多事情了” MVP 1996年，Taligent公司的CTO，Mike Potel在一篇論文中提出Model-View-Presenter的概念。 在這個時期，主流的View的概念跟經(jīng)典MVC中的那個“永遠(yuǎn)不應(yīng)該知道用戶輸入”的View有了很大的差別，它通常指本文中所述的控件，此時在Mike眼中，輸入已經(jīng)是由View獲得的了： Model-View-Presenter是在MVC的基礎(chǔ)上，進(jìn)一步規(guī)定了Controller中的一些概念而成的： 對，所以，不論你按照Mike還是Trygve的理解方式，MVP和MVC的依賴關(guān)系圖應(yīng)該是一！模！一！樣！的！因?yàn)镸ike的論文里說了“we refer to this kind（指應(yīng)用程序全局且使用interactor, command以及selection概念的） of controller as a presenter”。presenter它就是一種Controller??！ 把依賴關(guān)系畫成這樣也是醉了??！不管你信不信我反正是不信啊！ 標(biāo)記語言和MVVM 隨著20世紀(jì)初web的崛起，HTML跟JS這樣標(biāo)記語言+程序語言的組合模式開始變得令人注目。逐漸推出的Flex、Sliverlight、QT、WPF、JSF、Cocoa等UI系統(tǒng)不約而同地選擇了標(biāo)記語言來描述界面。 在這樣的架構(gòu)中，View（或者說叫控件，不但是從依賴關(guān)系上跟程序的其他部件解耦，而且從語言上跟其它部分隔離開來。 標(biāo)記語言的好處是，它可以由非專業(yè)的程序員產(chǎn)生，通過工具或者經(jīng)過簡單培訓(xùn)，一些設(shè)計(jì)師可以直接產(chǎn)生用標(biāo)記語言描述的UI。想要突破這個限制使得View跟其它部分異常耦合可能性也更低。 然而這樣的系統(tǒng)架構(gòu)中，MVC和MVP模式已經(jīng)不能很好地適用了。微軟架構(gòu)師John Gossman在WPF的XAML模式推出的同時，提出了MVVM的概念。 WPF得MVVM正式說明了它的View的概念跟MVC中的View的概念的區(qū)別。這里簡單畫了一下： 在MVVM模式中，數(shù)據(jù)綁定是最重要的概念，在MVC和MVP中的View和Model的互相通訊，被以雙向綁定的方式替代，這進(jìn)一步把邏輯代碼變成了聲明模式。 結(jié)語 從經(jīng)典MVC到MVVM，UI架構(gòu)經(jīng)過數(shù)次重大變遷，一些概念也在不斷變化，架構(gòu)和底層環(huán)境互相影響、適配，我認(rèn)為時至今日，經(jīng)典MVC已經(jīng)不再是UI架構(gòu)的正常選項(xiàng)。 更糟糕的是，今天無數(shù)經(jīng)過演繹的MVC實(shí)現(xiàn)（如backbone）和科普文，要么是原本作者概念已經(jīng)很混亂，摻雜私貨，要么為了適配現(xiàn)代的標(biāo)記語言和控件模式，自己修改了經(jīng)典MVC中的一些概念和耦合關(guān)系。實(shí)際上今天MVC已經(jīng)沒法作為一種交流的標(biāo)準(zhǔn)詞匯了。 寫此文，希望大家能了解些歷史上的發(fā)展歷程，莫被不嚴(yán)謹(jǐn)?shù)奈恼抡`導(dǎo)。 |
|
|
