一篇文章瞭解架構模式：MVC/MVP/MVVM

架構模式的文章不少，好理解的沒有幾個。大部分文章出現的主要問題有：

• 沒有設定好做用域：前端MVC是改造過的MVC，和後臺MVC有明顯的區別，不能一律而論
• 沒有實際的例子：實際的例子對應平常的工做，沒有就很難產生共鳴，從而形成看一次忘一次的困擾。
• 沒有明確的目的：理解架構模式的真正意義是什麼？虛擬DOM和組件化在MV*中的位置？

題目開的太大，必定有不少疏忽錯誤的地方，也懇請你們指出。

1. MV*

1.1 後端MVC與前端MVC

從實現上來講，主要能夠分爲後端MVC和前端MVC兩種。這兩種MVC的不一樣點以下：

能夠看到，前端的MVC實際上是爲了解決前端複雜JS模塊化的問題，從後端MVC的V分出來的MVC，與後端MVC並無直接的關係。前端的MVC中，M佔的比例很低，只指代數據。然後端V的比例很低，只有模版的部分。

1.2 MVC/MVP/MVVM

能夠清晰的看出，這三個架構的區別在「M與V聯繫」的部分。下面咱們針對這一部分作一個對比：

• Controller: 負責監聽View的用戶事件，獲得數據後Controller作一些處理，而後渲染View。

固然，在一些後端MVC架構裏，Model也能夠直接渲染View模版，但這只是不一樣變種的實現，這裏很少作討論。

可是隨時邏輯的複雜，這樣的處理遇到了很難調試的問題。因爲View必定要運行在UI環境下，並且Model或者Controller和View強耦合，沒有辦法單獨驗證應用邏輯的正確性。當出了問題以後，由於各個模塊是耦合在一塊兒的，也不能快速判斷到底是哪一個模塊出現的問題。所以，MVP模式出現了。

• Presenter: 比起Controller，Presenter會調用View層提供的接口去渲染Model。這樣作有幾點好處：

  • 面向接口編程
  • 更好的解耦
  • 方便作單元測試

如今P和V解耦了，P能夠本身作單元測試了。軟件結構劃分的更加清楚，邏輯清晰並方便調試。可是這一切都來自於一個前提：View層要提供接口。當一個UI複雜起來的時候，View層須要提供的接口是不少的，這自己也是一種開發調試的成本。因此，MVVM應運而生。

• ViewModel: 比起MVP中View須要本身提供API，MVVM在VM中構建一組狀態數據（state data），做爲View狀態的抽象。而後經過雙向數據綁定（data binding）使VM中的狀態數據（state data）與View中的顯示狀態（screen state）保持一致。這樣，VM中的展現邏輯只須要修改對應的狀態數據，就能夠控制View的狀態，從而避免在View上開發大量的接口。

VM有沒有什麼缺點？有的，當UI比較簡單的時候，使用VM就會使業務邏輯變得複雜，有過度設計的嫌疑。因此VM只適合複雜UI交互的項目。

2. 舉個栗子

栗子🌰：如今用戶下拉刷新一個頁面，頁面上出現10條新的新聞，新聞總數從10條變成20條。那麼MVC、MVP、MVVM的處理依次是：

1. View獲取下拉事件，通知Controller
2. Controller向後臺Model發起請求，請求內容爲下拉刷新
3. Model得到10條新聞數據，傳遞給Controller
4. Controller拿到10條新聞數據，可能作一些數據處理，而後拿處理好的數據渲染View
    MVC: 拿到UI節點，渲染10條新聞
    MVP: 經過View提供的接口渲染10條新聞
    MVVM: 無需操做，只要VM的數據變化，經過數據雙向綁定，View直接變化

3. 瞭解架構的意義

最大的意義是站在創造者的角度上去思考問題，他們爲何要這麼設計，這樣作又有什麼樣的好處。固然，也有助於咱們理解其餘相關的知識。等到將來的某一天，當咱們遇到更復雜的狀況，用今天的MVVM也不能解決的時候，就能夠順着這樣的思考脈絡，從新進行架構設計，散發出本身的光。

備註：虛擬DOM與組件化
不論是虛擬DOM也好，仍是組件化也罷，都是一種開發策略，而不是架構模式上考慮的問題。換句話說，它們與MV*是兩個維度上的事情。因此把虛擬DOM和組件化扯入到MVC，MVP，MVVM的差別中並無意義。

參考文獻

1. 《淺析 MVC, MVP 與 MVVM之間的異同》
2. 《先後端MVC的思考》