MVP Pattern: Part 2 Supervising Controller

Supervising Controller與Passive View的不同點在於,它允許View直接獲取Model的資料,獲取的手段可以透過事件附帶的參數,或是透過事件通知後,再自行獲取資料。

雖然講是這樣講,但對於還不認識MVP的人來說,應該還沒理解到Supervising Controller的模糊地帶。

先來看看類別圖,下圖是Supervising Controller的架構。

然後和Passive View的比較。

模糊的邊界

雖然一看到類別圖,應該就能明顯的理解到,View能夠直接從Model取得資料。
但Presenter和View對Model的控制權差別是什麼?

這裡就是MVP概念內的模糊邊界,我們都知道Model負責處理資料,但View與Presenter之間的界定並沒有很明確的規則。

從一開始的問題開始思考

我們在決定使用MVP模式之前,應該是碰到了什麼問題,然後才決定要使用模式。
(不要忘了,永遠都是先碰到問題,才決定要用設計模式)
(雖然熟了之後會習慣性的跳過這層思考)

所以回想一下,我們碰到的問題是:
邏輯層很難去控制隨時可能會改變表現邏輯的圖像層

因此隨之而來的解決辦法:
邏輯層只管觸發事件,會有其它物件來處理圖像層如何表現
(這個物件就是Presenter)

因此Passive View的作法是由View處理每一個表現手法,並將其管理完全的交給了Presenter。

然而如果有實作過Passive View,應該會發現,有時候資料的變動根本不會有延遲表現的問題,實在沒有必要透過事件附帶的參數來傳遞,而且如果View只是單純的從Model獲取資料,而不對Model做任何其它操作,也不會造成什麼副作用。

模糊的邊界●續

雖然我的講述順序是從Passive View開始說,可能導致Passive View看起來像是最一開始的MVP變體版本。然而,其實Supervising Controller才是比較接近原版本的變體,其原因也是因為MVP是MVC的變形版本,其在一開始還保留著MVC的View與Model要資料同步的概念。

注意到剛剛那一句了嗎?「MVC的View與Model要資料同步的概念」。

如果說Passive View是完全對View封閉Model的資料,
那麼Supervising Controller就是開放一部份的Model資料。
這就是Supervising Controller的關鍵差異點。

Supervising Controller硬翻成中文就是「監督的Controller」,這個Controller實際上指的就是Presenter。那Presenter是要控制什麼呢?Presenter仍然是負責控制View如何表現的管理者,也仍然會註冊Model的事件,只是開放了部份的讀取權限給View。

至於這個「部份」是多少呢?這裡引述Martin Fowler的講法:”…as much of this as reasonable…”,也就是「合理範圍內」。有沒有感到十分模糊呢?

舉個例子,Model的X資料發生了變動,而且低於了某個標準值,這時候擲出了2個事件,「X資料變動」和「低於標準值」。View接收了「X資料變動」的事件,並自行改變了螢幕上的X資料數值。Presenter收到了「低於標準值」的事件,因此呼叫View使用警告式的表現。

MVP模式核心概念是「Presenter負責控制視覺層」,雖然模糊,如果進行完全控制,包含了表現手法與資料顯示的控制,那就是Passive View;如果只負責如何表現,將資料獲取交給View自行處理,那就是Supervising Controller。

總結

看到這裡,你應該能夠理解:MVP的模糊邊界,取決於設計者想要開放多少資料給View自行取得,而到底是Passive View還是Supervising Controller,似乎也不那麼重要了。

這裡要注意的是,不論是Passive View還是Supervising Controller,View本身還是有視覺面的邏輯操作,只是將其封裝好,交給Presenter呼叫。

之所以特別這麼說,是因為第三變體的Presentation Model(MVVM的前身)則是完全將視覺面的邏輯操作拔出來,移到Presenter內。Presentation Model寫起來十分的囉嗦麻煩,這大概也是為什麼後來Microsoft發明了MVVM及其支援框架WPF和Silverlight。

下一篇開始,要透過實例展示為何我們Unity開發者在什麼狀況下會用到MVP模式,以及如何實現。

參考資料:
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
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.4964&rep=rep1&type=pdf
4. 翁博原 (2016). “淺談MVVM架構”
http://www.syscom.com.tw/ePaper_New_Content.aspx?id=498&EPID=219&TableName=sgEPArticle

發佈留言

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