盡管MVC早已不是什么新鮮話題了，但是從近些年一些優(yōu)秀MVC框架的設(shè)計(jì)上，我們還是會(huì)發(fā)現(xiàn)MVC在架構(gòu)設(shè)計(jì)上的一些新亮點(diǎn)。本文將對(duì)傳統(tǒng)MVC架構(gòu)中的一些弊病進(jìn)行解讀，了解一些優(yōu)秀MVC框架是如何化解這些問(wèn)題的，揭示其中所折射出的設(shè)計(jì)思想與設(shè)計(jì)理念。

　　MVC回顧　　

　　作為一種經(jīng)典到不能再經(jīng)典的架構(gòu)模式，MVC的成功有其必然的道理，這個(gè)道理不同的人會(huì)有不同的解讀，筆者最認(rèn)同的一種觀點(diǎn)是：通過(guò)把職責(zé)、性質(zhì)相近的成分歸結(jié)在一起，不相近的進(jìn)行隔離，MVC將系統(tǒng)分解為模型、視圖、控制器三部分，每一部分都相對(duì)獨(dú)立，職責(zé)單一，在實(shí)現(xiàn)過(guò)程中可以專注于自身的核心邏輯。MVC是對(duì)系統(tǒng)復(fù)雜性的一種合理的梳理與切分，它的思想實(shí)質(zhì)就是“關(guān)注點(diǎn)分離”。至于MVC三元素的職責(zé)劃分與相互關(guān)系，這里不再贅述，下圖給出了非常細(xì)致的說(shuō)明。

圖1：MVC組件的功能和關(guān)系

　　View與Controller的解耦：mediator+二次事件委派　　

　　筆者早年開(kāi)發(fā)基于swing的GUI應(yīng)用時(shí)，在架構(gòu)MVC的實(shí)踐過(guò)程中深刻體會(huì)到了view與controller之間的緊密耦合問(wèn)題。在很多事件驅(qū)動(dòng)的GUI框架里，如swing，用戶對(duì)view的任何操作都會(huì)觸發(fā)一個(gè)事件，然后在listener的響應(yīng)方法里進(jìn)行處理。如果讓view自己注冊(cè)成為事件的listener，則必須要在view中加入對(duì)controller的引用，這不是MVC希望看到的，因?yàn)檫@樣view和controller就形成了緊密的耦合關(guān)系。若將controller注冊(cè)為listener，則事件響應(yīng)將由controller承擔(dān)，這又會(huì)導(dǎo)致controller處理其不該涉及的展現(xiàn)邏輯，造成view和controller難以解耦的原因在于：多數(shù)的用戶請(qǐng)求都包含一定成分的展現(xiàn)邏輯和一定成分的業(yè)務(wù)邏輯，兩種邏輯揉合在一個(gè)請(qǐng)求里，在處理的時(shí)候，view與controller很難合理地分工。解決這一問(wèn)題的關(guān)鍵是要在view與controller之間建立一種可以將展現(xiàn)邏輯與業(yè)務(wù)邏輯進(jìn)行有效分割的機(jī)制，在這方面，PureMVC的設(shè)計(jì)非常值得參考，它通過(guò)引入mediator+二次事件委派機(jī)制很好的解決了view與controller之間的緊耦合問(wèn)題。

　　Mediator是一種設(shè)計(jì)模式，這種模式在組件化的圖形界面框架中似乎有著普遍的應(yīng)用場(chǎng)景，即使是在四人幫的《設(shè)計(jì)模式》一書(shū)中，也使用了一個(gè)圖形界面程序的示例來(lái)講解mediator。mediator的設(shè)計(jì)用意在于通過(guò)一個(gè)媒介對(duì)象，完成一組對(duì)象的交互，避免對(duì)象間相互引用，產(chǎn)生復(fù)雜的依賴關(guān)系。mediator應(yīng)用于圖形界面程序時(shí)，往往作為一組關(guān)系緊密的圖形組件的交互媒介，完成組件間的協(xié)調(diào)工作(比如點(diǎn)選某一按鈕，其他組件將不可用)。在PureMVC中，mediator被廣泛應(yīng)用，其定位也發(fā)生了微妙的變化，它不再只是圖形組件間的媒介，同時(shí)也成為了圖形組件與command之間的媒介，這使得它不再是可選的，而是成為了架構(gòu)中的必需設(shè)施。對(duì)應(yīng)到傳統(tǒng)MVC架構(gòu)中，mediator就是view與controller之間的媒介（當(dāng)然，也依然是view之間的媒介），所有從view發(fā)出的用戶請(qǐng)求都經(jīng)過(guò)了mediator再傳遞給controller，它的出現(xiàn)在一定程度上緩解了view與controller的緊密耦合問(wèn)題。

　　當(dāng)view、mediator和controller三者被定義出來(lái)，并進(jìn)行了清晰的職責(zé)劃分后，剩下的問(wèn)題就是如何將它們串聯(lián)起來(lái)，以完成一個(gè)用戶請(qǐng)求了，在這方面，事件機(jī)制起到了至關(guān)重要的作用。事件機(jī)制可以讓當(dāng)前對(duì)象專注于處理其職責(zé)范圍內(nèi)的事務(wù)，而不必關(guān)心超出部分由誰(shuí)來(lái)處理以及怎樣處理，當(dāng)前對(duì)象只需要廣播一個(gè)事件，就會(huì)有對(duì)此事件感興趣的其他對(duì)象出來(lái)接手下一步的工作，當(dāng)前對(duì)象與接手對(duì)象之間不存在直接依賴，甚至感知不到彼此的存在，這是事件機(jī)制被普遍認(rèn)為是一種松耦合機(jī)制的重要原因。講到這里插一句題外話，在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design）里，著名的Domain Event模式也是有賴于事件機(jī)制的這一特性被創(chuàng)造出來(lái)的，其用意正是為了保證領(lǐng)域模型的純凈，避免領(lǐng)域模型對(duì)repository和service的直接依賴。回到PureMVC，我們來(lái)看在處理用戶請(qǐng)求的過(guò)程中，事件機(jī)制是如何串聯(lián)view、mediator和controller的。在PureMVC里，當(dāng)一個(gè)用戶請(qǐng)求下達(dá)時(shí)，圖形組件先在自身的事件響應(yīng)方法中實(shí)現(xiàn)與自身相關(guān)的展現(xiàn)邏輯，然后收集數(shù)據(jù)，將數(shù)據(jù)置入一個(gè)新的event中，將其廣播出去，這是第一次事件委派。這個(gè)event會(huì)被一個(gè)mediator監(jiān)聽(tīng)到，如果處理該請(qǐng)求需要其他圖形組件的協(xié)助，mediator會(huì)協(xié)調(diào)它們處理應(yīng)由它們承擔(dān)的展現(xiàn)邏輯，然后mediator再次發(fā)送一個(gè)event(這次的event在PureMVC里稱之為notification)，這個(gè)event會(huì)促使某個(gè)command執(zhí)行，完成業(yè)務(wù)邏輯的計(jì)算，這是第二次事件委派。在兩次事件委派中，第一次事件委派讓當(dāng)事圖形組件完成“處理其職責(zé)范圍內(nèi)的展現(xiàn)邏輯”后，得以輕松“脫身”，免于被“協(xié)調(diào)其他圖件處理剩余展現(xiàn)邏輯”和“選擇并委派業(yè)務(wù)對(duì)象處理業(yè)務(wù)邏輯”所拖累。而“協(xié)調(diào)其他圖形組件處理剩余展現(xiàn)邏輯”顯然是mediator的職責(zé)，于是第一次廣播的事件被委派給了mediator。mediator在完成圖形組件的協(xié)調(diào)工作后，并不會(huì)插手“選擇并委派業(yè)務(wù)對(duì)象處理業(yè)務(wù)邏輯”的工作，這不是它的職責(zé)，因此，第二次事件委派發(fā)生了，一個(gè)新的event由mediator廣播出去，后被某個(gè)command響應(yīng)到，由command完成了最后的工作——“選擇并委派業(yè)務(wù)對(duì)象處理業(yè)務(wù)邏輯”。

圖2：mediator+二次事件委派機(jī)制

　　總結(jié)起來(lái)，PureMVC是通過(guò)在view與controller之間引入mediator，讓view與controller變成間接依賴，用戶請(qǐng)求從view到mediator，再?gòu)膍ediator到controller均以事件方式委派，mediator+二次事件委派的組合可以說(shuō)是一種“強(qiáng)力”的解耦機(jī)制，它實(shí)現(xiàn)了view與controller之間的完全解耦。

　　從Controller到Command，自然粒度的回歸　　

　　目前，很多平臺(tái)的主流MVC框架在設(shè)計(jì)上都引入了command模式，command模式的引入改變了傳統(tǒng)MVC框架的結(jié)構(gòu)，受沖擊最大的就是controller。在過(guò)去傳統(tǒng)的MVC架構(gòu)里，一個(gè)controller可能有多個(gè)方法，每個(gè)方法往往對(duì)應(yīng)一個(gè)user action，因此，一個(gè)controller往往對(duì)應(yīng)多個(gè)user action，而在基于command的MVC架構(gòu)里，一個(gè)command往往只對(duì)應(yīng)一個(gè)user action。傳統(tǒng)MVC架構(gòu)里將一個(gè)user action委派到某個(gè)controller的某個(gè)方法的過(guò)程，在基于command的MVC架構(gòu)里變成了將useraction與command一一綁定的過(guò)程。如果說(shuō)傳統(tǒng)controller的管理方式是在user action與model之間建立“集中式”的映射，那么基于command的管理方式就是在user action與model之間建立“點(diǎn)對(duì)點(diǎn)式”的直連映射。

圖3：從基于Controller到基于Command的架構(gòu)演進(jìn)

　　主流MVC框架向command轉(zhuǎn)型是有原因的，除了command自身的優(yōu)勢(shì)之外，一個(gè)非常重要的原因就是：由于缺少合理的組織依據(jù)，controller的粒度很難拿捏。controller不同于view與model，view與model都有各自天然的粒度組織依據(jù)，view的組織粒度直接承襲用戶界面設(shè)計(jì)，model的組織粒度則是依據(jù)某種分析設(shè)計(jì)思想（如OOA/D）進(jìn)行領(lǐng)域建模的結(jié)果，controller需要同時(shí)協(xié)調(diào)view與model，但是view與model的組織結(jié)構(gòu)和粒度都是不對(duì)等的，這就使得controller面臨一個(gè)“在多大視圖范圍內(nèi)溝通與協(xié)調(diào)多少領(lǐng)域?qū)ο?rdquo;的問(wèn)題，由于找不出合理的組織依據(jù)，設(shè)計(jì)者在設(shè)計(jì)controller時(shí)往往感到無(wú)所適從。相比之下，command則完全沒(méi)有controller的困惑，因?yàn)閏ommand有一個(gè)天然的組織依據(jù)，這就是user action。針對(duì)一個(gè)user action設(shè)計(jì)一個(gè)command，然后將兩者映射在一起，是一件非常自然而簡(jiǎn)單的事情。不過(guò)，需要說(shuō)明的是這并不意味著所有command的粒度是一樣的，因?yàn)椴煌膗ser action所代表的業(yè)務(wù)量是不同的，因此也決定了command是有“大”有“小”的。遵循良好的設(shè)計(jì)原則，對(duì)某些較“大”的command進(jìn)行分解，從中抽離出一些可復(fù)用的部分封裝成一些較“小”的command是值得推薦的。很多MVC框架就定義了一些相關(guān)的接口和抽象類用于支持基于組合模式的命令拼裝。

　　不管是基于controller還是基于command，MVC架構(gòu)中界定的“協(xié)調(diào)view與model交互”的控制器職責(zé)是不會(huì)變的，都需要相應(yīng)的組件和機(jī)制去承載與實(shí)現(xiàn)。在基于command的架構(gòu)里，command承擔(dān)了過(guò)去controller的部分職責(zé)，從某種意義上說(shuō)command是一種細(xì)粒度的controller，但是command的特性是偏“被動(dòng)”的。一方面，它對(duì)于view和model的控制力比controller弱化了很多， 比如，一般情況下command是不會(huì)直接操縱view的。另一方面，它不知道自己與什么樣的user action映射在了一起，也不知道自己會(huì)在何種情況下被觸發(fā)執(zhí)行。支撐command的運(yùn)行需要額外的注冊(cè)、綁定和觸發(fā)機(jī)制，是這些機(jī)制加上command一起實(shí)現(xiàn)了controller的職責(zé)。由于現(xiàn)在多數(shù)基于command的MVC框架都實(shí)現(xiàn)并封裝了這些重要的機(jī)制，所以從某種意義上說(shuō)，是這些框架自身扮演了controller角色。

　　小結(jié)　　

　　本文主要分析了過(guò)去傳統(tǒng)MVC架構(gòu)中存在的兩大弊病：view與controller的緊密耦合以及controller粒度難以把控的問(wèn)題，介紹了一些MVC框架是如何應(yīng)對(duì)這些問(wèn)題的，這些設(shè)計(jì)方案所體現(xiàn)出的優(yōu)秀設(shè)計(jì)思想是非常值得學(xué)習(xí)的。

　　[i] 圖片來(lái)源：http://Java.sun.com/blueprints/patterns/MVC-detailed.html

　　[ii] PureMVC是一種MVC框架，最初使用ActionScript 3實(shí)現(xiàn)，現(xiàn)在在多種語(yǔ)言平臺(tái)上有實(shí)現(xiàn)版本。官方站點(diǎn)：http://puremvc.org/ 。

it知識(shí)庫(kù)：從MVC框架看MVC架構(gòu)的設(shè)計(jì)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。