MVP Pattern: Part 1 Passive View

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

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。