關於MV*模式的一己之見，科普向

一直對mv*模式不太瞭解，終於趁着週末閒暇之餘試着去理解了如下，如下是我的總結，歡迎討論，若有錯誤請指教。

初

傳統mvc

mvc是一套設計模式的組合，最初是用於解決客戶端圖形界面應用程序的模塊化問題。

因爲用戶界面邏輯的更改每每要比業務邏輯更頻繁，而且在某些狀況下，應用程序須要以不一樣的方式來顯示同一數據等...諸多問題下，解決方案mvc就此誕生。

Model-View-Controller (MVC) 將程序劃分爲三層

• 模型 model封裝了程序指定的數據和邏輯（數據與業務）

• 視圖 view是對數據的顯示（界面）

• 控制器 controller可以響應用戶操做來通知model進行更新（只是通知，真實處理是由model自身執行）或者view的更新（事件）

model不僅是數據的整合，還包含了對數據進行處理的能力。

三者依賴和調用關係能夠參考下圖，主要是懶得畫。

依賴：能夠很明確的看到view和controller都依賴於model。

調用：

1. view接收到輸入，轉發給controller
2. controller 對輸入進行預處理後，調用匹配的model接口
3. model執行業務邏輯，變動數據後經過觀察者/訂閱模式通知全部已註冊的觀察者（view）
4. view收到model變動通知，請求更新後的數據，更新界面
複製代碼

關於調用關係能夠看出，mvc主要由觀察者模式構築，策略模式（controller能夠算做view的策略之一）以及其餘模式做爲輔助

依賴關係能夠在調用流程中獲得驗證，view因爲是直接向model請求數據並更新的，因此view實質上是知道model內數據的相關結構的，controller同理。這就致使了view與controller沒法脫離model，而且不可在其餘程序內部複用。

被動mvc

時代的發展，致使如今web應用的大行其道。

與客戶端圖形界面程序不一樣，web應用主要是經過http協議進行通訊，但http協議是單工協議而且是無狀態的，服務器沒法直接給客戶端推送數據，這也就致使了view訂閱model更新的模式被打破。

變動後web應用mvc模式大體流程爲：

1. 客戶端發送請求
2. 服務端經過路由調用相應的controller ，對來自客戶端得請求進行格式化預處理而後調用相應的 model 接口
3. model執行業務邏輯，使用數據渲染模版視圖，服務器回覆請求
5. 客戶端更新
複製代碼

演化

mvp

因爲mvc模式下的view與model的高度耦合，view沒法被組件化，複用程度低，因此mvp被提出

mvp直接切斷了view和model的綁定關係，解除了兩者的耦合。

controller 被替換（重命名）成了 presenter

mvp調用改變爲：

1. view接收到輸入，轉發給presenter
2. presenter對輸入進行預處理後，調用匹配的model接口
3. model執行業務邏輯，變動數據後經過觀察者模式通知presenter
4. presenter獲取更新後的數據，經過view提供的更新接口更新進行界面更新
複製代碼

實質上mvp就是mvc的另外一形式，presenter相比controller包含了更多的邏輯變得厚重（接受model的變動通知，與更新view的能力）。而view再也不依賴model，對於model以及presenter內的數據與業務徹底無感知，因此view能夠被抽象用於不一樣的應用中，只要提供對應的接口。

mvvm

mvvm是mvp的改良版，相對於mvp而言，在依賴關係上與調用關係上都沒有什麼變化，因此就不放圖了:)

mvp相比mvc來講，它抽離了view提升了模塊化程度，但presenter層既承擔了對view事件的預處理，又須要提供對於view的數據同步，致使了邏輯過於繁瑣厚重，難以開發與維護。

因而Model-View-ViewModel被提出，vm承載了presenter的功能，而且將model與view之間的數據更新抽離出來，提供了自動化的能力，開發人員沒必要再手動維護model與view之間的更新邏輯，能夠更專一於核心業務的開發。

mvc => mvp => mvvm 模式的更新，本質上是因爲項目複雜度不斷增長，新的需求被不斷被提出，爲了維持現狀而被迫的升級改良。

新模式這方面，新模式是不可能有新模式的，這輩子不可能有新模式的。換模式又不會搞，就是改良模式這種東西，才能維持的了生活這樣子。

前端

終於到前端了，做爲本職工做，前端戰五渣，雖然不懂，但仍是要勉強一寫，關於模式的理論在上文中已經大體介紹了一遍，下面只是一些關於模式與前端框架的雜談。

前端框架與庫千千萬，模式卻很少，也就mvc與mvvm佔主流。

Angular與Vue能夠算是主流的mvvm框架/庫，因爲Angular只是淺顯的走過一次教程因此就不提了。

Vue

關於Vue，在我看來，框架自身能夠算是一層vm，至於咱們寫的模版，天然是view。但有不少人認爲model應該是data也就是數據。但我認爲，開發人員所寫的js大多都屬於model。

Vue的實現能夠分爲兩步，對數據的劫持與解析dom後的數據監聽（訂閱者），實現了一套data=>view，view=>data的關係，用於自動化處理數據，開發者無需關注dom的更新，只須要爲對應的事件來編寫匹配的，用於更新data的函數便可（包含了ajax對於後端的請求）。

先後端分離的模式下，後端基本上只須要提供RESTful API便可。

React

React 起源於 Facebook 的內部項目，由於該公司對市場上全部 JavaScript MVC 框架，都不滿意，就決定本身寫一套，用來架設 Instagram 的網站。

React應該是一個屬於mvc的視圖庫，功能很是簡單而純粹，根據state渲染view。

末

關於react沒有多寫，第一是感受言盡於此，描述的挺清楚的。其次是由於寫這篇總結純屬意外，原本前兩天在看一些flux實現與redux源碼（才四五百行，註釋都還寫的挺清楚，對react有興趣的朋友能夠看看）而後莫名其妙就開始看mvc相關內容，跑偏了，後面就放棄治療了。

若是有機會的話，下一篇估計會寫關於flux=>redux的文章，react留到下一篇再聊。

---

參考資料以下。

微軟msdn：MVC模式

阮一峯：談談MVC模式

阮一峯：MVC，MVP 和 MVVM 的圖示

百度文庫：深刻淺出設計模式之MVC

界面之下：還原真實的MV*模式