本文將為大家講述的是.NET中的MVP模式的十四條規則，希望能對大家用好MVP模式有所幫助。
.NET程序設計不光是對于Visual Studio 2010這樣的工具使用上，或者一些小技巧。還包括一些設計理念和設計規則，這些反而是促進程序員進步的源泉。
一、CAB(Componsable Application Block)基于14條MVP規則
為了讓所有的人都能夠閱讀上面提及的那篇文章，我將其轉載我個人的博客中，有興趣的讀者可以仔細閱讀(《Design Rules for Model-View-Presenter》)。文章作者提出的觀點和我在《談談關于MVP模式中V-P交互問題》中的觀點是一致的，即Presenter對于View應該是相對透明的，View不能直接對Presenter進行操作，目的是實現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)。文章作者傾向采用事件注冊的方式實現Presenter和View，不過我不太清楚具體是注冊View還是Presenter的時間。在《談談關于MVP模式中V-P交互問題》中對MVP的實現手段，我采用的是在Presenter注冊View的事件。關于View和Presenter的分離，我的做法作得更加徹底一點——根本就不給開發者從View調用Presenter的機會。
文中提出了關于CAB的14條編寫符合MVP規范的規則，在這里我特將其翻譯成中文：
1、所有的View(包括View的接口)的名稱應該以View作為后綴，比如TaskView/ITaskView;
2、所有的Presenter名稱應該以Presenter作為后綴，比如TaskViewPresenter;
3、Presenter完成Use Case處理邏輯，對GUI控件的處理應該在View中實現;
4、View調用Presenter的方法應該像觸發事件異常，通過調用OnXxx方法的方式來實現;
5、應該盡可能地限制View對Presenter的調用，并且調用的方式限于按照“事件”的形式，比如_presenter.OnViewReady();
6、View不允許通過Presenter直接調用Model和Service，并且Presenter的方法應該是不具有返回值的;
7、Presenter必須通過View接口的方式調用View
8、除了對View接口成員的實現外，View中的其他方法不應該是public的;
9、除了CAB ModuleController 對View的加載和限制外，View只能被Presenter調用;
10、View接口方法應該基于Use Case的邏輯起一個有意義的名稱，比如SetDataSource這樣的方法名稱是不合法的;
11、View接口的成員應該僅限于方法，不應該包含屬性;
12、所有的數據應用保持在Model中
13、定義在View接口的方法不應該包含對GUI空間名稱的引用(比如AddExplorerBarGroup)，因為這會使Presenter知道View太多關于實現方面的細節;
14、盡量讓View的方法名稱反映Use Case的業務邏輯，這樣可以使你的代碼具有自表述性并更加易于理解。
再次回到《談談關于MVP模式中V-P交互問題》中討論的話題，在我看來，拋開1和2對View的Presenter命名的規范外，其余的12條規則體現了MVP關于View和Presenter之間應該具有的關系，以及我們應該采取的正確的Presenter和View交互方式。View和Presenter之間的關系，可以通過對Presenter的角色界定來體現，在整個MVP體系中Presenter扮演的是協調者的角色。
二、Presenter是協調者，是整個MVP體系的控制中心
如果我們將MVP體系比喻成一個社團(考慮到中國沒有黑社會，這里我們說社團)，我們經�？匆姷耐悄切┰谕饷娼哟娜耍憧梢詫⑺鼈兛闯墒荲iew。也就是說View是和外界打交道的人，是行動者，就像是到處砍人、收保護費，以及和別的社團搶地盤的都是這些處于社團基層的小混混一樣。View永遠處于處于幕前，和最終用戶進行交互，但是地位卻不高。對于用戶的UI交互請求該如何進行處理，View做不了主，它需要向大佬匯報。所以View永遠不可能是決策者，僅僅是一個匯報者而已。
Presenter才是真正的大佬、話事人，執龍頭杖的。Presenter生藏不露，最終用戶感知不但它的存在，就像社團大哥大都隱藏的比較好，甚至以政府官員(比如文強大哥)或者是電影公司老板(比如香港的XXX電影公司)的身份出現。但是，我們知道，他才是整個社團的主導、核心，是整個事務的決策者和執行者，使能夠調動相關資源的協調者，而這個事務，你可以理解為Use Case。也就是說，Presenter是對Use Case的反映，UI交互邏輯的處理流程定義在Presenter中，但是具體的實現并不是完全在Presenter中，這一點很重要，下面一節中我們還會談到。
我們還是把話題回到交互上面。這里的交互，即View和Presenter之間如果溝通，是比較特別的。談到溝通，很多人都會認為這是一個雙向的問題，而View和Presenter采用單向的溝通方式，這和某些上下級的溝通方式有點類似——下級單方地向上級匯報工作，上級單方的向下級下達命名。這在等級觀念深重社團中更是如此，我們習慣的場景是這樣的：小混混向大佬說：“我們的場子昨天晚上被砸了，懷疑是XXX干的”。大佬說：“恩，知道了，下去吧!”。真正有前途的小混混不會說“我們的場子昨天晚上被砸了，懷疑是XXX干的，我們什么時候去砍他?”。真正有范兒的大佬不會馬上命令你在什么時候、什么地點、帶多少兄弟去砍人，而在計劃實施的時候會向相關成員下達砍人的指令。
反映在真正View|Presenter的交互上面，就是說：View單純地將用戶的交互請求匯報給Presenter;Presenter接收到請求之后，整合相應的資源、執行相應的處理邏輯。對處理流程的某一個步驟，如果設置到業務邏輯和數據模型，則調用Model，如果涉及到對GUI控件的操作，還會調用View。View將交互請求遞交給Presenter之后，不需要考慮后續需要做什么，因為Presenter會在適當的時候命令View該如何做。
所以說，Presenter是整個體系的驅動著，View和Presenter不應該是一種拉的關系，而是一種推的關系。View將用戶交互請求推給Presenter，Presenter將數據推給View并驅動View完成相應的UI相應。 正因為如此，上面的MVP規則列表中才規定Presenter的方法不需要返回值，View的接口不需要定義屬性。實際在我個人看來，Presenter和View接口都應該只包含返回類型為void的方法即可。
三、Presenter不關注具體的實現細節
談到這里有人會說，所有的關于UI處理邏輯定義在Presenter中，那么會不會使Presenter變得臃腫不堪呢?持這種觀點的人實際上走入了另外一個誤區。我曾經看到過有人寫過這樣一個極端的例子——將View的所有控件都以屬性的方式公布出來，定義在View接口中，所有控件相關的操作都實現在Presenter中。很明顯這是不對的，雖然這個例子很極端，但是我想很多對MVP不是太了解的人或多或少會犯這種錯誤。
在上面一節中，我們說過UI交互邏輯的處理流程定義在Presenter中，但是具體的實現并不是完全在Presenter中。Presenter是藍圖的設計者，并不關注實現的細節。大佬只是制定行動計劃，真正砍人、收保護費和搶地盤這種操作性強的工種的還是屬于小混混們。
所以該View干的事一件也逃不了，只是View不考慮什么時候干，因為Presenter會在適當的時候通知你，View得保證隨叫隨到。為了保證Presenter能夠有效地控制View，需要將這些操作定義在接口中。既然定義在接口中，操作的粒度就不能太細。Presenter關于的是整個Use Case的處理流程，所以定義在View接口中的操作也應該采用處理流程相關的語言來定義。