本文將為大家講述的是.NET中的MVP模式的十四條規(guī)則，希望能對(duì)大家用好MVP模式有所幫助。
.NET程序設(shè)計(jì)不光是對(duì)于Visual Studio 2010這樣的工具使用上，或者一些小技巧。還包括一些設(shè)計(jì)理念和設(shè)計(jì)規(guī)則，這些反而是促進(jìn)程序員進(jìn)步的源泉。
一、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交互問題》中的觀點(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，不過我不太清楚具體是注冊(cè)View還是Presenter的時(shí)間。在《談?wù)勱P(guān)于MVP模式中V-P交互問題》中對(duì)MVP的實(shí)現(xiàn)手段，我采用的是在Presenter注冊(cè)View的事件。關(guān)于View和Presenter的分離，我的做法作得更加徹底一點(diǎn)——根本就不給開發(fā)者從View調(diào)用Presenter的機(jī)會(huì)。
文中提出了關(guān)于CAB的14條編寫符合MVP規(guī)范的規(guī)則，在這里我特將其翻譯成中文：
1、所有的View(包括View的接口)的名稱應(yīng)該以View作為后綴，比如TaskView/ITaskView;
2、所有的Presenter名稱應(yīng)該以Presenter作為后綴，比如TaskViewPresenter;
3、Presenter完成Use Case處理邏輯，對(duì)GUI控件的處理應(yīng)該在View中實(shí)現(xiàn);
4、View調(diào)用Presenter的方法應(yīng)該像觸發(fā)事件異常，通過調(diào)用OnXxx方法的方式來實(shí)現(xiàn);
5、應(yīng)該盡可能地限制View對(duì)Presenter的調(diào)用，并且調(diào)用的方式限于按照“事件”的形式，比如_presenter.OnViewReady();
6、View不允許通過Presenter直接調(diào)用Model和Service，并且Presenter的方法應(yīng)該是不具有返回值的;
7、Presenter必須通過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è)有意義的名稱，比如SetDataSource這樣的方法名稱是不合法的;
11、View接口的成員應(yīng)該僅限于方法，不應(yīng)該包含屬性;
12、所有的數(shù)據(jù)應(yīng)用保持在Model中
13、定義在View接口的方法不應(yīng)該包含對(duì)GUI空間名稱的引用(比如AddExplorerBarGroup)，因?yàn)檫@會(huì)使Presenter知道View太多關(guān)于實(shí)現(xiàn)方面的細(xì)節(jié);
14、盡量讓View的方法名稱反映Use Case的業(yè)務(wù)邏輯，這樣可以使你的代碼具有自表述性并更加易于理解。
再次回到《談?wù)勱P(guān)于MVP模式中V-P交互問題》中討論的話題，在我看來，拋開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)系，可以通過對(duì)Presenter的角色界定來體現(xiàn)，在整個(gè)MVP體系中Presenter扮演的是協(xié)調(diào)者的角色。
二、Presenter是協(xié)調(diào)者，是整個(gè)MVP體系的控制中心
如果我們將MVP體系比喻成一個(gè)社團(tuán)(考慮到中國(guó)沒有黑社會(huì)，這里我們說社團(tuán))，我們經(jīng)�？匆姷耐悄切┰谕饷娼哟娜�，你可以將它們看成是View。也就是說View是和外界打交道的人，是行動(dòng)者，就像是到處砍人、收保護(hù)費(fèi)，以及和別的社團(tuá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。也就是說，Presenter是對(duì)Use Case的反映，UI交互邏輯的處理流程定義在Presenter中，但是具體的實(shí)現(xiàn)并不是完全在Presenter中，這一點(diǎn)很重要，下面一節(jié)中我們還會(huì)談到。
我們還是把話題回到交互上面。這里的交互，即View和Presenter之間如果溝通，是比較特別的。談到溝通，很多人都會(huì)認(rèn)為這是一個(gè)雙向的問題，而View和Presenter采用單向的溝通方式，這和某些上下級(jí)的溝通方式有點(diǎn)類似——下級(jí)單方地向上級(jí)匯報(bào)工作，上級(jí)單方的向下級(jí)下達(dá)命名。這在等級(jí)觀念深重社團(tuán)中更是如此，我們習(xí)慣的場(chǎng)景是這樣的：小混混向大佬說：“我們的場(chǎng)子昨天晚上被砸了，懷疑是XXX干的”。大佬說：“恩，知道了，下去吧!”。真正有前途的小混混不會(huì)說“我們的場(chǎng)子昨天晚上被砸了，懷疑是XXX干的，我們什么時(shí)候去砍他?”。真正有范兒的大佬不會(huì)馬上命令你在什么時(shí)候、什么地點(diǎn)、帶多少兄弟去砍人，而在計(jì)劃實(shí)施的時(shí)候會(huì)向相關(guān)成員下達(dá)砍人的指令。
反映在真正View|Presenter的交互上面，就是說：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該如何做。
所以說，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)槿绱�，上面的MVP規(guī)則列表中才規(guī)定Presenter的方法不需要返回值，View的接口不需要定義屬性。實(shí)際在我個(gè)人看來，Presenter和View接口都應(yīng)該只包含返回類型為void的方法即可。
三、Presenter不關(guān)注具體的實(shí)現(xiàn)細(xì)節(jié)
談到這里有人會(huì)說，所有的關(guān)于UI處理邏輯定義在Presenter中，那么會(huì)不會(huì)使Presenter變得臃腫不堪呢?持這種觀點(diǎn)的人實(shí)際上走入了另外一個(gè)誤區(qū)。我曾經(jīng)看到過有人寫過這樣一個(gè)極端的例子——將View的所有控件都以屬性的方式公布出來，定義在View接口中，所有控件相關(guān)的操作都實(shí)現(xiàn)在Presenter中。很明顯這是不對(duì)的，雖然這個(gè)例子很極端，但是我想很多對(duì)MVP不是太了解的人或多或少會(huì)犯這種錯(cuò)誤。
在上面一節(jié)中，我們說過UI交互邏輯的處理流程定義在Presenter中，但是具體的實(shí)現(xiàn)并不是完全在Presenter中。Presenter是藍(lán)圖的設(shè)計(jì)者，并不關(guān)注實(shí)現(xiàn)的細(xì)節(jié)。大佬只是制定行動(dòng)計(jì)劃，真正砍人、收保護(hù)費(fèi)和搶地盤這種操作性強(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)的語言來定義。