詳解MVP模式的十四條清規(guī)戒律
.NET程序設(shè)計(jì)不光是對(duì)于Visual Studio 2010這樣的工具使用上，或者一些小技巧。還包括一些設(shè)計(jì)理念和設(shè)計(jì)規(guī)則，這些反而是促進(jìn)程序員進(jìn)步的源泉。
之前寫(xiě)了一篇名稱(chēng)為《談?wù)勱P(guān)于MVP模式中V-P交互問(wèn)題》的文章，主要表達(dá)本人對(duì)于MVP模式下（主要針對(duì)Passive View變體）View和Presenter之間的關(guān)系，以及它們之間的交互應(yīng)該采用怎樣的原則和方式的看法。園子里的朋友對(duì)此展開(kāi)了一些討論，尤其是是一個(gè)叫做非空的朋友轉(zhuǎn)述了另一篇文章提出的關(guān)于CAB中關(guān)于MVP模式的14條規(guī)則，和本人的觀點(diǎn)有很多相似之處，當(dāng)然也有一些不一致的地方。為此，在本篇文章中，就此進(jìn)行一些必要的補(bǔ)充。
一、CAB（Componsable Application Block）基于14條MVP規(guī)則
為了讓所有的人都能夠閱讀上面提及的那篇文章，我將其轉(zhuǎn)載我個(gè)人的博客中，有興趣的讀者可以仔細(xì)閱讀（《Design Rules for Model-View-Presenter》）。文章作者提出的觀點(diǎn)和我在《談?wù)勱P(guān)于MVP模式中V-P交互問(wèn)題》中的觀點(diǎn)是一致的，即Presenter對(duì)于View應(yīng)該是相對(duì)透明的，View不能直接對(duì)Presenter進(jìn)行操作，目的是實(shí)現(xiàn)Presenter和View之間的分離（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）。文章作者傾向采用事件注冊(cè)的方式實(shí)現(xiàn)Presenter和View，不過(guò)我不太清楚具體是注冊(cè)View還是Presenter的時(shí)間。在《談?wù)勱P(guān)于MVP模式中V-P交互問(wèn)題》中對(duì)MVP的實(shí)現(xiàn)手段，我采用的是在Presenter注冊(cè)View的事件。關(guān)于View和Presenter的分離，我的做法作得更加徹底一點(diǎn)——根本就不給開(kāi)發(fā)者從View調(diào)用Presenter的機(jī)會(huì)。
文中提出了關(guān)于CAB的14條編寫(xiě)符合MVP規(guī)范的規(guī)則，在這里我特將其翻譯成中文：
1、所有的View（包括View的接口）的名稱(chēng)應(yīng)該以View作為后綴，比如TaskView/ITaskView；
2、所有的Presenter名稱(chēng)應(yīng)該以Presenter作為后綴，比如TaskViewPresenter；
3、Presenter完成Use Case處理邏輯，對(duì)GUI控件的處理應(yīng)該在View中實(shí)現(xiàn)；
4、View調(diào)用Presenter的方法應(yīng)該像觸發(fā)事件異常，通過(guò)調(diào)用OnXxx方法的方式來(lái)實(shí)現(xiàn)；
5、應(yīng)該盡可能地限制View對(duì)Presenter的調(diào)用，并且調(diào)用的方式限于按照“事件”的形式，比如_presenter.OnViewReady();
6、View不允許通過(guò)Presenter直接調(diào)用Model和Service，并且Presenter的方法應(yīng)該是不具有返回值的；
7、Presenter必須通過(guò)View接口的方式調(diào)用View
8、除了對(duì)View接口成員的實(shí)現(xiàn)外，View中的其他方法不應(yīng)該是public的；
9、除了CAB ModuleController 對(duì)View的加載和限制外，View只能被Presenter調(diào)用；
10、View接口方法應(yīng)該基于Use Case的邏輯起一個(gè)有意義的名稱(chēng)，比如SetDataSource這樣的方法名稱(chēng)是不合法的；
11、View接口的成員應(yīng)該僅限于方法，不應(yīng)該包含屬性；
12、所有的數(shù)據(jù)應(yīng)用保持在Model中
13、定義在View接口的方法不應(yīng)該包含對(duì)GUI空間名稱(chēng)的引用（比如AddExplorerBarGroup），因?yàn)檫@會(huì)使Presenter知道View太多關(guān)于實(shí)現(xiàn)方面的細(xì)節(jié)；
14、盡量讓View的方法名稱(chēng)反映Use Case的業(yè)務(wù)邏輯，這樣可以使你的代碼具有自表述性并更加易于理解。
再次回到《談?wù)勱P(guān)于MVP模式中V-P交互問(wèn)題》中討論的話題，在我看來(lái)，拋開(kāi)1和2對(duì)View的Presenter命名的規(guī)范外，其余的12條規(guī)則體現(xiàn)了MVP關(guān)于View和Presenter之間應(yīng)該具有的關(guān)系，以及我們應(yīng)該采取的正確的Presenter和View交互方式。View和Presenter之間的關(guān)系，可以通過(guò)對(duì)Presenter的角色界定來(lái)體現(xiàn)，在整個(gè)MVP體系中Presenter扮演的是協(xié)調(diào)者的角色。
二、Presenter是協(xié)調(diào)者，是整個(gè)MVP體系的控制中心
如果我們將MVP體系比喻成一個(gè)社團(tuán)（考慮到中國(guó)沒(méi)有黑社會(huì)，這里我們說(shuō)社團(tuán)），我們經(jīng)常看見(jiàn)的往往是那些在外面接待的人，你可以將它們看成是View。也就是說(shuō)View是和外界打交道的人，是行動(dòng)者，就像是到處砍人、收保護(hù)費(fèi)，以及和別的社團(tuán)搶地盤(pán)的都是這些處于社團(tuán)基層的小混混一樣。View永遠(yuǎn)處于處于幕前，和最終用戶進(jìn)行交互，但是地位卻不高。對(duì)于用戶的UI交互請(qǐng)求該如何進(jìn)行處理，View做不了主，它需要向大佬匯報(bào)。所以View永遠(yuǎn)不可能是決策者，僅僅是一個(gè)匯報(bào)者而已。
Presenter才是真正的大佬、話事人，執(zhí)龍頭杖的。Presenter生藏不露，最終用戶感知不但它的存在，就像社團(tuán)大哥大都隱藏的比較好，甚至以政府官員（比如文強(qiáng)大哥）或者是電影公司老板（比如香港的XXX電影公司）的身份出現(xiàn)。但是，我們知道，他才是整個(gè)社團(tuán)的主導(dǎo)、核心，是整個(gè)事務(wù)的決策者和執(zhí)行者，使能夠調(diào)動(dòng)相關(guān)資源的協(xié)調(diào)者，而這個(gè)事務(wù)，你可以理解為Use Case。也就是說(shuō)，Presenter是對(duì)Use Case的反映，UI交互邏輯的處理流程定義在Presenter中，但是具體的實(shí)現(xiàn)并不是完全在Presenter中，這一點(diǎn)很重要，下面一節(jié)中我們還會(huì)談到。
我們還是把話題回到交互上面。這里的交互，即View和Presenter之間如果溝通，是比較特別的。談到溝通，很多人都會(huì)認(rèn)為這是一個(gè)雙向的問(wèn)題，而View和Presenter采用單向的溝通方式，這和某些上下級(jí)的溝通方式有點(diǎn)類(lèi)似——下級(jí)單方地向上級(jí)匯報(bào)工作，上級(jí)單方的向下級(jí)下達(dá)命名。這在等級(jí)觀念深重社團(tuán)中更是如此，我們習(xí)慣的場(chǎng)景是這樣的：小混混向大佬說(shuō)：“我們的場(chǎng)子昨天晚上被砸了，懷疑是XXX干的”。大佬說(shuō)：“恩，知道了，下去吧！”。真正有前途的小混混不會(huì)說(shuō)“我們的場(chǎng)子昨天晚上被砸了，懷疑是XXX干的，我們什么時(shí)候去砍他？”。真正有范兒的大佬不會(huì)馬上命令你在什么時(shí)候、什么地點(diǎn)、帶多少兄弟去砍人，而在計(jì)劃實(shí)施的時(shí)候會(huì)向相關(guān)成員下達(dá)砍人的指令。
反映在真正View|Presenter的交互上面，就是說(shuō)：View單純地將用戶的交互請(qǐng)求匯報(bào)給Presenter；Presenter接收到請(qǐng)求之后，整合相應(yīng)的資源、執(zhí)行相應(yīng)的處理邏輯。對(duì)處理流程的某一個(gè)步驟，如果設(shè)置到業(yè)務(wù)邏輯和數(shù)據(jù)模型，則調(diào)用Model，如果涉及到對(duì)GUI控件的操作，還會(huì)調(diào)用View。View將交互請(qǐng)求遞交給Presenter之后，不需要考慮后續(xù)需要做什么，因?yàn)镻resenter會(huì)在適當(dāng)?shù)臅r(shí)候命令View該如何做。
所以說(shuō)，Presenter是整個(gè)體系的驅(qū)動(dòng)著，View和Presenter不應(yīng)該是一種拉的關(guān)系，而是一種推的關(guān)系。View將用戶交互請(qǐng)求推給Presenter，Presenter將數(shù)據(jù)推給View并驅(qū)動(dòng)View完成相應(yīng)的UI相應(yīng)。 正因?yàn)槿绱耍厦娴腗VP規(guī)則列表中才規(guī)定Presenter的方法不需要返回值，View的接口不需要定義屬性。實(shí)際在我個(gè)人看來(lái)，Presenter和View接口都應(yīng)該只包含返回類(lèi)型為void的方法即可。
三、Presenter不關(guān)注具體的實(shí)現(xiàn)細(xì)節(jié)
談到這里有人會(huì)說(shuō)，所有的關(guān)于UI處理邏輯定義在Presenter中，那么會(huì)不會(huì)使Presenter變得臃腫不堪呢？持這種觀點(diǎn)的人實(shí)際上走入了另外一個(gè)誤區(qū)。我曾經(jīng)看到過(guò)有人寫(xiě)過(guò)這樣一個(gè)極端的例子——將View的所有控件都以屬性的方式公布出來(lái)，定義在View接口中，所有控件相關(guān)的操作都實(shí)現(xiàn)在Presenter中。很明顯這是不對(duì)的，雖然這個(gè)例子很極端，但是我想很多對(duì)MVP不是太了解的人或多或少會(huì)犯這種錯(cuò)誤。
在上面一節(jié)中，我們說(shuō)過(guò)UI交互邏輯的處理流程定義在Presenter中，但是具體的實(shí)現(xiàn)并不是完全在Presenter中。Presenter是藍(lán)圖的設(shè)計(jì)者，并不關(guān)注實(shí)現(xiàn)的細(xì)節(jié)。大佬只是制定行動(dòng)計(jì)劃，真正砍人、收保護(hù)費(fèi)和搶地盤(pán)這種操作性強(qiáng)的工種的還是屬于小混混們。
所以該View干的事一件也逃不了，只是View不考慮什么時(shí)候干，因?yàn)镻resenter會(huì)在適當(dāng)?shù)臅r(shí)候通知你，View得保證隨叫隨到。為了保證Presenter能夠有效地控制View，需要將這些操作定義在接口中。既然定義在接口中，操作的粒度就不能太細(xì)。Presenter關(guān)于的是整個(gè)Use Case的處理流程，所以定義在View接口中的操作也應(yīng)該采用處理流程相關(guān)的語(yǔ)言來(lái)定義。
原文標(biāo)題：大話MVP
鏈接：http://www.cnblogs.com/artech/archive/2010/04/12/1710681.html
【編輯推薦】
