提到MVC，你會(huì)想到什么？三層架構(gòu)？設(shè)計(jì)模式？JSP？老掉牙？面相對(duì)象制造器？
先來(lái)聽(tīng)個(gè)故事吧。
引子
《我是歌手》后，實(shí)力唱將林志炫算是迎來(lái)了事業(yè)第二春。小N這天想去網(wǎng)上買(mǎi)一張林志炫的正版CD收藏下，和網(wǎng)店小二聊了下。
店小二：不好意思，暫時(shí)賣(mài)完了，您要是想要的話，可以幫您訂一張。
小N想了下，和店小二談好價(jià)格，決定訂一張，雙方談妥。
店小二給老板打電話：有個(gè)顧客想買(mǎi)林志炫的《One Take》專(zhuān)輯，咱們店里沒(méi)現(xiàn)貨了，您給臺(tái)灣那邊的廠家打電話，讓他們發(fā)一張過(guò)來(lái)吧。
老板說(shuō)：Ok，沒(méi)問(wèn)題。
老板于是給臺(tái)灣唱片行打電話：某某經(jīng)理你好，麻煩你明天給我寄一張林志炫《One Take》過(guò)來(lái)吧。
經(jīng)理說(shuō)：好的，明天早上就發(fā)貨。
第二天晚上就到貨了，于是店小二馬上發(fā)貨給小N。又過(guò)了1天，小N收到CD了，開(kāi)心的不得了。
我們來(lái)分析一下。
這個(gè)例子中，涉及到四個(gè)人物，小N、店小二、老板、臺(tái)灣某經(jīng)理。關(guān)系如下圖所示：
其實(shí)這就是一個(gè)簡(jiǎn)單的MVC流程。
- 服務(wù)員對(duì)應(yīng)View，是與用戶直接交流，響應(yīng)用戶的交互操作。
- 老板對(duì)應(yīng)Controller，負(fù)責(zé)接收View傳過(guò)來(lái)的請(qǐng)求以及相應(yīng)數(shù)據(jù)，并將加工的請(qǐng)求通知給唱片行經(jīng)理。
- 臺(tái)灣唱片行經(jīng)理對(duì)應(yīng)Model。因?yàn)槌邢鄬?duì)獨(dú)立，它不依賴于某個(gè)實(shí)體店而存在，就像Model不依賴于如何被顯示或者如何被操作一樣。
緣起
MVC模式最早由Trygve Reenskaug大師在1974年參加X(jué)erox論壇時(shí)提出，在論文《A note on DynaBook requirements》中，大師說(shuō)，MVC最初是為了在人類(lèi)世界模型和電腦數(shù)據(jù)模型中建立一種橋梁而產(chǎn)生的架構(gòu)，旨在用同一份模型來(lái)滿足不同應(yīng)用場(chǎng)景需求。
MVC模式，最初名稱為 Thing-Model-View-Editor模式，在7個(gè)月之后，模式更名為Model-View-Control。其中，原Things模塊關(guān)心user如何觸發(fā)交互問(wèn)題，之后被弱化（即之后的Event機(jī)制）；原Editor模塊只負(fù)責(zé)提供一個(gè)用戶與一個(gè)或多個(gè)View模塊進(jìn)行交互的公共接口，此交互過(guò)程不經(jīng)過(guò)Model模塊。之后Editor模塊被強(qiáng)化為Controller，全面負(fù)責(zé)用戶與View、Model的交互。
在Thing-Model-View-Editor 模型演化之后，MVC各模塊的原始定義為：
- Model模型層：負(fù)責(zé)“知識(shí)”的供給。Model可以為一個(gè)對(duì)象，或者包含一組對(duì)象的結(jié)構(gòu)體。為了能準(zhǔn)確的定位問(wèn)題，Model應(yīng)當(dāng)提供一個(gè)能唯一識(shí)別問(wèn)題的部分，這樣才真正能夠?qū)崿F(xiàn)Model的復(fù)用。
- View視圖層：View是它所屬M(fèi)odel的展示部分。它的作用是可以最原始的展示所屬M(fèi)odel的幾個(gè)特定屬性，并隱藏掉其它屬性。因此View扮演的角色類(lèi)似于一個(gè)與展示相關(guān)的“過(guò)濾器”。
- Controller控制層：controller層是用戶與系統(tǒng)聯(lián)系的紐帶。它提供給用戶一組可供用戶輸入的視圖集，并且能夠保證每一個(gè)視圖都顯示在恰當(dāng)?shù)奈恢蒙稀Ｖ螅珻ontroller接收到用戶在視圖層的輸入后，將他們轉(zhuǎn)化為特定的消息，并且分發(fā)這些消息給相關(guān)的Views。
MVC模式出道至今已近40年，但仍威風(fēng)不減。雖然現(xiàn)今流行的MVC框架大都是經(jīng)過(guò)了優(yōu)化，各個(gè)模塊的含義和作用均得到了增強(qiáng)，但是，萬(wàn)變不離其宗，MVC模式的“宗”始終沒(méi)變，這也是為什么MVC模式能夠屹立至今的原因。那到底MVC的“宗”是什么？
不變
世界，每一刻都是嶄新的。蘇子說(shuō)“自其變者而觀之，則天地曾不能以一瞬。”可是，蘇子又說(shuō)過(guò)：“自其不變者而觀之，則物與我皆無(wú)盡也”。也就是說(shuō)，變化是絕對(duì)的，不變是相對(duì)的。從另一個(gè)角度來(lái)說(shuō)，變中蘊(yùn)含著不變。一旦從變中抽象出不變之后，就要解決兩個(gè)問(wèn)題：其一，何時(shí)變；其二，如何變。其實(shí)，這種從變中抽象出不變的過(guò)程，正對(duì)應(yīng)了從無(wú)框架代碼過(guò)渡到MVC框架代碼的過(guò)程。
不變，對(duì)應(yīng)Model層。上文有述，這是MVC誕生的根本。一個(gè)好的系統(tǒng)，一定有一個(gè)相對(duì)穩(wěn)定的Model層，不然它可以被斷定是存在設(shè)計(jì)缺陷的，不論是從產(chǎn)品層面還是從設(shè)計(jì)層面。何時(shí)變，對(duì)應(yīng)了View層。View層負(fù)責(zé)接收用戶直接的交互，并將交互抽象為事件通知Controller，這解決了何時(shí)變要解決的問(wèn)題。如何變，對(duì)應(yīng)了Controller層，它在可以變的時(shí)機(jī)，進(jìn)行了變的行為，并且通知了不變，這也正是“怎么變”的職責(zé)所在。
以上，為一次用“不變”來(lái)描述“變”的過(guò)程。
猛回頭
在向身邊的人推薦MVC時(shí)，我耳邊經(jīng)常飄著這樣的話：“MVC，都20多年了，不是早就過(guò)時(shí)了嗎？”
我認(rèn)為，MVC是否過(guò)時(shí)可以從兩方面進(jìn)行判斷：
- MVC是否還在被使用
- MVC的思想是否已經(jīng)消亡
對(duì)于第一點(diǎn)，我舉兩個(gè)例子：呼風(fēng)喚雨的Apple公司的開(kāi)發(fā)框架Cocoa至今還在使用MVC模式；GoogleMap的JS API中的對(duì)象基類(lèi)，名字就叫MVC Object。
對(duì)于第二點(diǎn)，我覺(jué)得這是一個(gè)由分母變化而引起的錯(cuò)覺(jué)。因?yàn)樵贛VC提出之初，正是計(jì)算機(jī)軟件架構(gòu)貧瘠的時(shí)候，MVC橫空出世占領(lǐng)半壁江山，順?biāo)浦邸５沁@么多年過(guò)去了，各種框架早已“百家爭(zhēng)鳴、百花齊放”，MVC不可能不被進(jìn)一步優(yōu)化，這些被優(yōu)化、改進(jìn)過(guò)的框架雖然有可能不再以MVC冠名，但這不代表MVC在它們身上的影響力已經(jīng)不在。畢竟從抽象層次上，由“變”到“不變”的變化，是只可能被演化，但不可能再被抽象了的變化。
面向?qū)ο?VS 面向原型 VS ?
MVC往往和面向?qū)ο舐?lián)系在一起。至少，以傳統(tǒng)MVC模式實(shí)現(xiàn)的代碼帶有很強(qiáng)的面向?qū)ο蟮娘L(fēng)格。面向?qū)ο蟮木幊田L(fēng)格，在一些情況下會(huì)把簡(jiǎn)單的問(wèn)題變得異常復(fù)雜，因此有人說(shuō)，MVC會(huì)把代碼小題大做。我覺(jué)得，用面向?qū)ο蟮乃枷雭?lái)對(duì)世界進(jìn)行建模，難免會(huì)有這種情況，因?yàn)槭澜绮⒉皇敲嫦驅(qū)ο蟮摹Ｄ牵澜缬秩鏙avaScript支持者那樣，是面向原型的嗎？
如果，世界既不是面向?qū)ο蟮模植皇敲嫦蛟偷模牵澜缬质鞘裁矗?/p>
