本文將為大家講述的是.NET中的MVP模式的十四條規則，希望能對大家用好MVP模式有所幫助。
.NET程(cheng)序(xu)設計(ji)(ji)不光是(shi)對于Visual Studio 2010這(zhe)樣(yang)的(de)工具(ju)使用上，或(huo)者一些小技巧。還包括一些設計(ji)(ji)理念和設計(ji)(ji)規則，這(zhe)些反而是(shi)促進(jin)程(cheng)序(xu)員(yuan)進(jin)步的(de)源泉。
一、CAB(Componsable Application Block)基于14條MVP規則
為了讓(rang)所(suo)有的(de)(de)(de)(de)(de)人都能夠閱(yue)(yue)讀上面提及(ji)的(de)(de)(de)(de)(de)那篇文章，我(wo)(wo)(wo)將(jiang)其轉(zhuan)載我(wo)(wo)(wo)個(ge)人的(de)(de)(de)(de)(de)博(bo)客中(zhong)，有興趣(qu)的(de)(de)(de)(de)(de)讀者(zhe)(zhe)(zhe)可以仔細閱(yue)(yue)讀(《Design Rules for Model-View-Presenter》)。文章作(zuo)者(zhe)(zhe)(zhe)提出的(de)(de)(de)(de)(de)觀點(dian)和我(wo)(wo)(wo)在《談(tan)談(tan)關于(yu)MVP模式中(zhong)V-P交互(hu)問題》中(zhong)的(de)(de)(de)(de)(de)觀點(dian)是(shi)一(yi)(yi)致的(de)(de)(de)(de)(de)，即(ji)Presenter對(dui)于(yu)View應該是(shi)相對(dui)透明的(de)(de)(de)(de)(de)，View不(bu)能直接對(dui)Presenter進行(xing)操作(zuo)，目的(de)(de)(de)(de)(de)是(shi)實(shi)現Presenter和View之間(jian)(jian)的(de)(de)(de)(de)(de)分(fen)離(li)(The generated code is not quite as I would like it, I prefer that the view has no knowledge of the presenter and no direct access to it either as this gives a cleaner separation between views and presenters)。文章作(zuo)者(zhe)(zhe)(zhe)傾向采用(yong)事件注(zhu)冊的(de)(de)(de)(de)(de)方式實(shi)現Presenter和View，不(bu)過(guo)我(wo)(wo)(wo)不(bu)太清楚具體是(shi)注(zhu)冊View還是(shi)Presenter的(de)(de)(de)(de)(de)時間(jian)(jian)。在《談(tan)談(tan)關于(yu)MVP模式中(zhong)V-P交互(hu)問題》中(zhong)對(dui)MVP的(de)(de)(de)(de)(de)實(shi)現手(shou)段，我(wo)(wo)(wo)采用(yong)的(de)(de)(de)(de)(de)是(shi)在Presenter注(zhu)冊View的(de)(de)(de)(de)(de)事件。關于(yu)View和Presenter的(de)(de)(de)(de)(de)分(fen)離(li)，我(wo)(wo)(wo)的(de)(de)(de)(de)(de)做(zuo)法(fa)作(zuo)得更加徹底一(yi)(yi)點(dian)——根(gen)本就不(bu)給開(kai)發(fa)者(zhe)(zhe)(zhe)從(cong)View調用(yong)Presenter的(de)(de)(de)(de)(de)機會。
文中(zhong)提出(chu)了關于(yu)CAB的(de)14條(tiao)編(bian)寫符合MVP規(gui)范的(de)規(gui)則，在(zai)這里我特將其翻(fan)譯(yi)成(cheng)中(zhong)文：
1、所有(you)的View(包括View的接口)的名稱應該以View作為后綴，比如TaskView/ITaskView;
2、所有的Presenter名稱應(ying)該以(yi)Presenter作(zuo)為后綴，比如TaskViewPresenter;
3、Presenter完成Use Case處理邏輯，對GUI控件(jian)的處理應該在View中(zhong)實現;
4、View調(diao)用Presenter的方法(fa)應該像觸發事(shi)件異常，通過調(diao)用OnXxx方法(fa)的方式來實現;
5、應該盡可能地限(xian)制View對(dui)Presenter的(de)調用，并且調用的(de)方式(shi)限(xian)于(yu)按照“事件”的(de)形(xing)式(shi)，比如_presenter.OnViewReady();
6、View不(bu)允許通過Presenter直接(jie)調用(yong)Model和Service，并且(qie)Presenter的(de)方法應該是不(bu)具有(you)返回(hui)值(zhi)的(de);
7、Presenter必須通過View接口(kou)的方式調用(yong)View
8、除了對View接(jie)口成員的(de)(de)實(shi)現外(wai)，View中的(de)(de)其他方(fang)法不應(ying)該是public的(de)(de);
9、除了(le)CAB ModuleController 對(dui)View的加載和限制外，View只能被Presenter調用;
10、View接口方(fang)(fang)法(fa)應該(gai)基于Use Case的邏輯起一個(ge)有意義的名稱(cheng)(cheng)，比如(ru)SetDataSource這樣(yang)的方(fang)(fang)法(fa)名稱(cheng)(cheng)是不(bu)合法(fa)的;
11、View接口的成員應該僅限于(yu)方(fang)法(fa)，不應該包含屬性(xing);
12、所有的(de)數據(ju)應用保持在Model中
13、定義在View接口的(de)方(fang)法不應該包含對GUI空間名稱(cheng)的(de)引用(比如AddExplorerBarGroup)，因為這會(hui)使Presenter知道View太多關于實(shi)現方(fang)面的(de)細(xi)節;
14、盡量讓View的(de)方法名稱反映(ying)Use Case的(de)業務邏輯(ji)，這樣可以使你的(de)代碼具有自(zi)表述性(xing)并更(geng)加(jia)易于理解(jie)。
再次回到《談(tan)談(tan)關(guan)于(yu)(yu)MVP模式中V-P交(jiao)互問題》中討(tao)論(lun)的(de)(de)話(hua)題，在我看來，拋開1和2對View的(de)(de)Presenter命(ming)名的(de)(de)規范外，其余的(de)(de)12條規則體現了MVP關(guan)于(yu)(yu)View和Presenter之間應該(gai)具有的(de)(de)關(guan)系，以(yi)及我們應該(gai)采取的(de)(de)正確的(de)(de)Presenter和View交(jiao)互方式。View和Presenter之間的(de)(de)關(guan)系，可以(yi)通過(guo)對Presenter的(de)(de)角色界定來體現，在整個MVP體系中Presenter扮演的(de)(de)是協調者的(de)(de)角色。
二、Presenter是協調者，是整個MVP體系的控制中心
如(ru)果我們(men)(men)將(jiang)MVP體系比喻(yu)成一個社團(考慮到(dao)中國(guo)沒(mei)有黑社會，這里我們(men)(men)說(shuo)社團)，我們(men)(men)經常看見的往往是(shi)那些在外面接待的人(ren)，你可(ke)以(yi)(yi)將(jiang)它們(men)(men)看成是(shi)View。也就是(shi)說(shuo)View是(shi)和(he)(he)外界打交(jiao)道(dao)的人(ren)，是(shi)行(xing)動者，就像是(shi)到(dao)處(chu)砍(kan)人(ren)、收保護費(fei)，以(yi)(yi)及和(he)(he)別的社團搶地盤的都是(shi)這些處(chu)于社團基(ji)層的小混混一樣。View永遠(yuan)(yuan)處(chu)于處(chu)于幕前，和(he)(he)最終用戶進(jin)行(xing)交(jiao)互(hu)，但是(shi)地位(wei)卻不高。對(dui)于用戶的UI交(jiao)互(hu)請求(qiu)該如(ru)何進(jin)行(xing)處(chu)理，View做(zuo)不了主，它需(xu)要向大佬(lao)匯(hui)報。所(suo)以(yi)(yi)View永遠(yuan)(yuan)不可(ke)能是(shi)決策者，僅僅是(shi)一個匯(hui)報者而已。
Presenter才是真正的(de)(de)(de)大佬、話事(shi)人，執(zhi)(zhi)龍頭杖(zhang)的(de)(de)(de)。Presenter生藏不露(lu)，最終用戶感知(zhi)不但(dan)(dan)它的(de)(de)(de)存(cun)在(zai)，就像社(she)團大哥(ge)大都隱(yin)藏的(de)(de)(de)比(bi)(bi)較好，甚至以政(zheng)府(fu)官員(比(bi)(bi)如文強大哥(ge))或(huo)者是電(dian)影(ying)公司(si)老(lao)板(比(bi)(bi)如香(xiang)港的(de)(de)(de)XXX電(dian)影(ying)公司(si))的(de)(de)(de)身(shen)份(fen)出現。但(dan)(dan)是，我們知(zhi)道，他才是整(zheng)個社(she)團的(de)(de)(de)主導(dao)、核(he)心，是整(zheng)個事(shi)務的(de)(de)(de)決策(ce)者和執(zhi)(zhi)行(xing)者，使能夠調(diao)動相關資源的(de)(de)(de)協(xie)調(diao)者，而這個事(shi)務，你可以理(li)解為Use Case。也就是說，Presenter是對Use Case的(de)(de)(de)反映，UI交(jiao)互邏輯的(de)(de)(de)處理(li)流程(cheng)定義(yi)在(zai)Presenter中(zhong)(zhong)，但(dan)(dan)是具體的(de)(de)(de)實現并不是完(wan)全在(zai)Presenter中(zhong)(zhong)，這一點很重要(yao)，下面一節中(zhong)(zhong)我們還會談到。
我們(men)還是把話題回到交互(hu)上(shang)(shang)(shang)面(mian)。這(zhe)(zhe)里的(de)(de)交互(hu)，即View和Presenter之間(jian)如果溝(gou)通(tong)，是比較特別的(de)(de)。談到溝(gou)通(tong)，很多人(ren)(ren)都會認(ren)為這(zhe)(zhe)是一個雙向(xiang)的(de)(de)問題，而(er)View和Presenter采用單向(xiang)的(de)(de)溝(gou)通(tong)方(fang)(fang)式，這(zhe)(zhe)和某(mou)些上(shang)(shang)(shang)下(xia)(xia)(xia)級(ji)的(de)(de)溝(gou)通(tong)方(fang)(fang)式有(you)點(dian)類似——下(xia)(xia)(xia)級(ji)單方(fang)(fang)地向(xiang)上(shang)(shang)(shang)級(ji)匯報工作，上(shang)(shang)(shang)級(ji)單方(fang)(fang)的(de)(de)向(xiang)下(xia)(xia)(xia)級(ji)下(xia)(xia)(xia)達命(ming)名。這(zhe)(zhe)在(zai)等級(ji)觀(guan)念(nian)深(shen)重社團中更(geng)是如此(ci)，我們(men)習慣的(de)(de)場(chang)景是這(zhe)(zhe)樣的(de)(de)：小混(hun)混(hun)向(xiang)大(da)佬(lao)說(shuo)：“我們(men)的(de)(de)場(chang)子昨天晚上(shang)(shang)(shang)被砸了，懷(huai)疑是XXX干(gan)的(de)(de)”。大(da)佬(lao)說(shuo)：“恩(en)，知道了，下(xia)(xia)(xia)去吧!”。真正(zheng)有(you)前途的(de)(de)小混(hun)混(hun)不會說(shuo)“我們(men)的(de)(de)場(chang)子昨天晚上(shang)(shang)(shang)被砸了，懷(huai)疑是XXX干(gan)的(de)(de)，我們(men)什(shen)么(me)時(shi)候去砍(kan)他(ta)?”。真正(zheng)有(you)范兒的(de)(de)大(da)佬(lao)不會馬上(shang)(shang)(shang)命(ming)令你在(zai)什(shen)么(me)時(shi)候、什(shen)么(me)地點(dian)、帶多少兄弟(di)去砍(kan)人(ren)(ren)，而(er)在(zai)計劃實施(shi)的(de)(de)時(shi)候會向(xiang)相(xiang)關(guan)成(cheng)員下(xia)(xia)(xia)達砍(kan)人(ren)(ren)的(de)(de)指令。
反映(ying)在真正View|Presenter的(de)(de)交互(hu)上面，就是說：View單純地(di)將用戶(hu)的(de)(de)交互(hu)請求匯報給(gei)Presenter;Presenter接收到(dao)請求之后，整合相(xiang)應的(de)(de)資源、執行相(xiang)應的(de)(de)處理邏輯。對(dui)處理流程的(de)(de)某一個步驟，如果(guo)設置到(dao)業務邏輯和數據模型，則調(diao)用Model，如果(guo)涉及到(dao)對(dui)GUI控件的(de)(de)操作，還會(hui)調(diao)用View。View將交互(hu)請求遞交給(gei)Presenter之后，不需要考慮后續需要做什么，因(yin)為Presenter會(hui)在適當的(de)(de)時候命令View該如何做。
所以說，Presenter是(shi)整個體系的(de)驅(qu)動著，View和(he)Presenter不應該是(shi)一種(zhong)拉的(de)關系，而(er)是(shi)一種(zhong)推的(de)關系。View將用戶(hu)交互請求(qiu)推給(gei)Presenter，Presenter將數據推給(gei)View并驅(qu)動View完成相應的(de)UI相應。 正因為如此，上面的(de)MVP規(gui)(gui)則列表(biao)中才規(gui)(gui)定(ding)Presenter的(de)方(fang)法(fa)(fa)不需要(yao)返回(hui)值，View的(de)接口(kou)不需要(yao)定(ding)義屬性。實際在我(wo)個人看來，Presenter和(he)View接口(kou)都應該只包含返回(hui)類型為void的(de)方(fang)法(fa)(fa)即(ji)可。
三、Presenter不關注具體的實現細節
談到這(zhe)(zhe)里有(you)(you)人(ren)會(hui)說(shuo)，所有(you)(you)的(de)關于UI處理邏輯(ji)定義在Presenter中，那么會(hui)不(bu)(bu)會(hui)使(shi)Presenter變(bian)得臃腫(zhong)不(bu)(bu)堪呢(ni)?持這(zhe)(zhe)種觀點的(de)人(ren)實際上走入了另(ling)外一(yi)個(ge)誤區(qu)。我曾經看到過有(you)(you)人(ren)寫過這(zhe)(zhe)樣一(yi)個(ge)極端(duan)的(de)例(li)子(zi)——將View的(de)所有(you)(you)控件都以屬性(xing)的(de)方式公布出來，定義在View接口中，所有(you)(you)控件相關的(de)操作(zuo)都實現(xian)在Presenter中。很(hen)明顯這(zhe)(zhe)是(shi)(shi)不(bu)(bu)對(dui)的(de)，雖然這(zhe)(zhe)個(ge)例(li)子(zi)很(hen)極端(duan)，但(dan)是(shi)(shi)我想(xiang)很(hen)多(duo)對(dui)MVP不(bu)(bu)是(shi)(shi)太了解的(de)人(ren)或多(duo)或少會(hui)犯這(zhe)(zhe)種錯誤。
在(zai)上面一節中，我們說過(guo)UI交互邏輯的(de)處理流程(cheng)定義在(zai)Presenter中，但是(shi)(shi)具體的(de)實現(xian)并(bing)不是(shi)(shi)完全在(zai)Presenter中。Presenter是(shi)(shi)藍圖的(de)設計(ji)者，并(bing)不關注實現(xian)的(de)細節。大佬只是(shi)(shi)制定行動計(ji)劃(hua)，真(zhen)正(zheng)砍人、收保護費(fei)和搶地盤這種(zhong)操作性強(qiang)的(de)工種(zhong)的(de)還是(shi)(shi)屬于小混混們。
所以(yi)該View干的事一(yi)件(jian)也逃不(bu)了(le)(le)，只是(shi)View不(bu)考慮什么時候干，因為(wei)Presenter會在(zai)適當的時候通知你(ni)，View得保證(zheng)隨叫隨到。為(wei)了(le)(le)保證(zheng)Presenter能夠(gou)有效地控制(zhi)View，需要(yao)將這些操(cao)(cao)作定(ding)義在(zai)接口中。既(ji)然(ran)定(ding)義在(zai)接口中，操(cao)(cao)作的粒度就不(bu)能太細。Presenter關(guan)于的是(shi)整個Use Case的處理(li)流程(cheng)(cheng)，所以(yi)定(ding)義在(zai)View接口中的操(cao)(cao)作也應該采用(yong)處理(li)流程(cheng)(cheng)相關(guan)的語言來定(ding)義。