MVP (Model View Presenter) 設計模式

在 GUI 的架構開發中，最顯為人知就是 MVC (Model View Controller) 了

而 MVP (Model View Presenter) 模式也類似於 MVC，從下圖我們可以看到 MVP 與 MVC 的區別

上圖參考於 http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/



從這張比較圖可以觀察到 MVP 模式中有兩個重點

1. MVP 並不像 MVC 中的 Model 和 View 會透過 Event 的方式渲染視圖上的結果，
    MVP 中的 Model 和 View 是不做任何溝通的，也就是說彼此也不知道雙方的存在，也無任何依賴關係

2. MVP 中的 Presenter 與 MVC 中的 Controller 角色類似，相當於 View 與 Model 之間的黏著劑
    但不同的是 Presenter 需要負責收集 Model 處理後的結果並通知 View 執行試圖更新的動作
    原因就是因為第一點所描述的 MVP 中的 Model 和 View 是不做任何溝通的
    簡單說 Presenter 負責 sync Model 與 View 之間的資料


如果從流程上(或上圖)來看，過程勢必如下

1. View 收到使用者的動作

2. 通知 Presenter

3. Presenter 向 Model 取資料

4. Model 處理好資料後回給 Presenter

5. Presenter 接收到資料並傳回給 View

6. View 將資料做呈現


從上面的流程可以察覺兩個問題

• M、V、P各個元件(Component)該如何溝通
• Presenter 負責的任務較繁重(當應用程式很大的時候)

先從第一個問題看起，元件之間要溝通勢必會關係到元件之間的耦合關係，如果用最簡單的

Function call，那麼元件間的耦合度勢必會提升不少，畢竟每個元件各自參考(reference)其相關的元件

在越大型的系統越難維護外，當一有變動時勢必也會連帶影響其他元件

在設計模式(Design Pattern)中，有幾個方法是可以解除元件之間的耦合

像是中介者模式(Mediator Pattern)或是觀察者模式(Observer Pattern)

再多數的 GUI 架構開發中多數都是使用觀察者模式，因此大部分的 MVP 模式中也主張用如此的方式

例如：View 通知 Presenter 與 Model 通知 Presenter 可以用事件(Event)或是回呼函式(callback Function) 來做到

所以一個更明確的 MVP 過程就類似下圖

再來剛剛提及的第二個問題

"Presenter 負責的任務較繁重(當應用程式很大的時候)"

Supervising Presenter 設計模式或許可以嘗試看看，下一篇就來介紹 Supervising Presenter

當然每個應用程式的特性或許會改變你最 MVP 架構的想法，這也是必然的

畢竟沒有一種設計模式或架構能夠完全滿足變動與需求