在差不多兩年的時間內，我們項目組幾十來號人都撲在一個項目上面。這是一個基于微軟SCSF（Smart Client Software Factory）的項目，客戶端是墨爾本一家事業單位。前兩周，我奉命負責對某個模塊進行Code Review工作，在此期間，發現了一些問題，也有了一些想法。不過，有些想法可能還不是很成熟，不能完全保證其正確性，有機會寫出來討論一下。今天來說說關于MVP的一些想法。

一、簡單講講MVP是什么玩意兒
如果從層次關系來講，MVP屬于Presentation層的設計模式。對于一個UI模塊來說，它的所有功能被分割為三個部分，分別通過Model、View和Presenter來承載。Model、View和Presenter相互協作，完成對最初數據的呈現和對用戶操作的響應，它們具有各自的職責劃分。Model可以看成是模塊的業務邏輯和數據的提供者；View專門負責數據可視化的呈現，和用戶交互事件的相對應。一般地，View會實現一個相應的接口；Presenter是一般充當Model和View的紐帶。

MVP具有很多的變體，其中最為常用的一種變體成為Passive View（被動視圖）。對于Passive View，Model、View和Presenter之間的關系如下圖所示。View和Modell之間不能直接交互，View通過Presenter與Model打交道。Presenter接受View的UI請求，完成簡單的UI處理邏輯，并調用Model進行業務處理，并調用View將相應的結果反映出來。View直接依賴Presenter，但是Presenter間接依賴View，它直接依賴的是View實現的接口。關于MVP和Passive View基本的常識性東西，不是本篇文章論述的重點，對此不清楚的讀者相信可以Google出很多相關的資料來，所以在這里就再多做介紹了。

二、Passive View模式的基本特征總結

Passive View，顧名思義，View是被動的。那么主動是誰呢？答案是Presenter。對于Presenter的主動性，我個人是這么理解的：

•Presenter是整個MVP體系的控制中心，而不是單純的處理View請求的人；
•View僅僅是用戶交互請求的匯報者，對于響應用戶交互相關的邏輯和流程，View不參與決策，真正的決策者是Presenter；
•View向Presenter發送用戶交互請求應該采用這樣的口吻：“我現在將用戶交互請求發送給你，你看著辦，需要我的時候我會協助你”，不應該是這樣：“我現在處理用戶交互請求了，我知道該怎么辦，但是我需要你的支持，因為實現業務邏輯的Model只信任你”；
•對于綁定到View上的數據，不應該是View從Presenter上“拉”回來的，應該是Presenter主動“推”給View的；
•View盡可能不維護數據狀態，因為其本身僅僅實現單純的、獨立的UI操作；Presenter才是整個體系的協調者，它根據處理用于交互的邏輯給View和Model安排工作。