MVP(Model-View-Presenter)模式，是MVC(Model-View-Controller)模式的變體，主要被使用在GUI的架構。其特徵是有個做為「中間人」的Presenter，負責協調Model和View之間的事件與資料變化。
Presenter的協調工作
Presenter藉由View與Model的介面註冊了事件。因此，當View或Model觸發了什麼事件，Presenter都會知道，並向另外一邊呼叫適當的函式。
舉個例子，當使用者點擊了介面上的按鈕，也就是從View觸發了此按鈕被點擊的事件。由於我們已經設定Presenter如果收到了這個事件，就應該呼叫Model的A()。
例子繼續，Model在執行A()的過程中，某個X資料出現了變化，由於我們告訴Model：「當X資料出現變化的時候，要觸發這個事件，外面有其它物件會接收。」因此Presenter收到了Model的X資料變化事件，但我們告訴Presenter：「處理此事件時，除了告訴View要更新X資料之外，還要讓View丟個花瓣特效。」
當然，Model根本不知道View那邊做了什麼，不管是花瓣特效、煙火特效、延遲更新、或是根本沒更新，Model根本管不著。Model只需要保證事件有正確觸發，其它的事情相信Presenter會處理好。
View也只管觸發規定的使用者操作事件。View根本不知道Model什麼時候會更新資料過來，反正Presenter會處理好。
以上已經把Passive View講完了
你可能會覺得「啥？這樣就講完了？」不過Passive View就是比較簡單易懂的變體。
Passive View，硬翻成中文就是「被動的View」，顧名思義就是View的行為基本上由Presenter來控制，View也不知道Model有什麼功能。
我們來看一下架構。
這是最原始的Passive View架構，Model和View都是透過事件與Presenter溝通。
如果你的Model很複雜，希望為Presenter做測試的時候，不要去管那麼複雜的Model，你也可以為Model開一個介面。這樣就可以用Test Double為Presenter寫測試。
後記
MVP並不像GoF的設計模式，對物件關係有嚴謹的設計，而是一個概念，因此有多種實現方式。1990年代最原始的MVP已經沒落，現代有兩個知名的變體，分別是Passive View和Supervising Controller。
其實還有第三種Presentation Model，不過我認為概念上跟原本的MVP已經有點落差，後來還根據此變體出現了另一個叫做MVVM(Model-View-ViewModel)的變體，因此這個系列文章不會討論Presentation Model。
下一篇，理所當然的要講Supervising Controller。
參考資料：
1. Mike Potel (1996). “MVP: Model-View-Presenter – The Taligent Programming Model for C++ and Java”.
http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
2. Martin Fowler (2006). “GUI Architectures”
https://martinfowler.com/eaaDev/uiArchs.html
3. Atomic Object LLC (2006). “Presenter First: Organizing Complex GUI Applications for Test-Driven Development”
https://kxcdn.atomicobject.com/uploads/archive/files/PresenterFirstAgile2006.pdf