[review] MVC與MVP

MVC基本職責

• Model : 提供商業邏輯功能、知會view狀態改變
• Controller :  接受輸入、事件，驅動model
• View : 呈現資料，連結Controller，乃至於提供互動介面

有個有點問題的MVC用於動態網頁的設計圖

在過去application實作方式，大多使得view直接認得model，但是model只是透過observer model通知view改變，藉以解構model跟view之間的耦合

所以即使到了動態網頁，應該也不全都是透過controller傳遞scalar data而應該是傳遞model的object

借用下面的圖片說明MVC model的一種life time流程，傳統GUI元件往往把view跟controller連結再一起，所以controller由view建立，事件也由view發起

MVP

上面是在於單機application的時候，往往model會存在記憶體中相當的時間，但是到了web application時代，因為每次請求都是一個新的狀態，換句話說就是stateless，元件的功能側重的變化是

• Model : 提供商業邏輯功能、保存資料、知會view狀態改變
• Controller :  接受請求，驅動model，控制流程
• View : 呈現資料，連結Controller，乃至於提供互動介面

重點在web模式下發生變化的model不是持續、有狀態(stateless)的存在，也就是沒有必要去通知view更新，也辦不到。controller變得接受請求，而比較不像是事件驅動，view由html取代，與controller的連結性以及互動也變得稀薄

由於應用場景的不同，使得MVC這個架構並不是很適合，而產生了新的變形

因為是stateless，所以每次請求都類似service，controller需要分配協調的功能性變弱。這設計模式進一步想解開model/view之間的耦合，連observer pattern都想擺脫掉，另外引入了matrin folwer的IoC思維

• View : 呈現資料以及對presenter提出請求
• Presenter : 提供services，只有特定的介面，所以view要建立合乎presenter的介面 (IoC)
• Model : 照舊XD，但是完全不必再去通知view

這樣的設計好或不好要看場合，由於拿掉了observer pattern，model的改變在web應用上很沒有問題，因為model是被動的，並不用及時通知前端(view)改變。所以在win form上面的設計model有時是跟presenter上是雙向溝通的，可以讓model通知presenter，進而更新view，這點在martin folwer的supervising controller上也有提到
有趣的是，這樣的想法比較接近一開始的圖，所以我說那張MVC的圖有問題XD



參考資料:
一個做得不錯的MVC投影片


Backbones.js
http://documentcloud.github.io/backbone

MVP實作參考
http://www.cnblogs.com/leoo2sk/archive/2010/01/28/mvp-in-practice-based-on-dot-net.html