前言
在web1.0時代時，那個時候程式猿還沒有前後端之分，更程式設計師開發的時候，都是要前後端一起寫的，前後端的程式碼都是雜揉在一起，如圖下
這種開發模式的話，開發的時候因為不需要和其他人員溝通協作，前後端都是程式碼都是寫在一起，優缺點如下：
優點：簡單快捷
缺點：程式碼難以維護
為了讓開發更佳便捷，程式碼更易於維護，前後端職責更加清晰。便衍生出MVC開發模式和框架，前端展示以模板的形式出現。我當時實習的時候，所在的公司開發模式就是使用這種開發模式，開發模式如圖：
使用這種分層架構，前後端職責清晰，程式碼也易於維護。但是這裡的MVC僅限於後端，前後端形成了一定的分離，前端只完成了後端開發中的view層
缺點：
1. 前端頁面開發效率不高
2. 前後端職責不夠清晰
自從Gmail的出現，ajax技術開始風靡全球。有了ajax之後，前後端的職責就更加清晰了。因為前端可以通過ajax與後端進行資料互動，因此，整體的架構圖也就變化成了下面這幅圖。
通過ajax與後臺伺服器進行資料交換，前端開發人員，只需要開發頁面這部分內容，資料可由後臺進行提供。而且ajax可以是的頁面實現部分，減少了服務端負載和流量消耗，使用者體驗也更佳。這時，才開始有專職的前端工程師，同時前端的類庫也慢慢的開始發展，例如當時最著名的jquery。
缺點：缺乏可行的開發模式承載更復雜的業務需求，頁面內容都雜糅在一起，一旦應用規模增大，就會導致專案難以維護。因此，前端的MVC框架也就隨之而來了
前端的MVC與後端類似，具備著view、controller和Model。
Model：負責儲存應用資料，與後端資料進行同步
Controller：負責業務邏輯，根據使用者行為對model資料進行修改
View：負責檢視展示，將model中的資料視覺化出來
三者形成了如圖所示的模型：
實際開發中，我們往往會看到另外一種模式：
但是，這種靈活可能導致嚴重的問題：
資料流混亂。如下圖：
view比較龐大，而Controller比較單薄：由於很多的開發者都會在view中寫一些邏輯程式碼，逐漸的就導致view中的內容越來越龐大，而controller變得越來越單薄
既然有缺陷，就會有變革，前端的變化中，似乎跳過了MVP這種模式，是因為Angular早早的將MVVM框架帶入了前端。MVP模式雖然前端開發中並不常見，但是在安卓等原生開發中，開發中還是會考慮它
MVP
MVP和MVC很接近，P指的是Presenter，presenter可以理解為一箇中間人，它負責著View和Model之間的資料流動 ，防止View和model之間直接交流。我們可以看一下圖示
我們通過圖可以看到，presenter負責和Model進行雙向互動，這種互動方式，相對於MVC來說，少了一些靈活，View變成了被動檢視，並且本身變得很小，雖然它分了view和model，但是應用逐漸變大之後，導致presenter的體積增大，難以維護，要解決這個問題。或許可以從MVVM的思想中找到答案
MVVM
什麼是MVVM？MVVM可以分解為Model-View—ViewModel，ViewModel可以理解為在presenter基礎上的進階版本，如圖所示：
ViewModel通過實現一套資料響應式機制自動響應Model中資料變化；
同時ViewModel會實現一套更新策略自動將資料變化轉換為檢視更新
通過事件監聽響應View中互動修改Model中資料
這樣在ViewModel中就嫻熟了大量DOM操作程式碼
MVVM在保持VIEW和Model鬆耦合的同時，還減少了維護他們關係的程式碼，使使用者專注於業務邏輯，兼顧開發效率和可維護性
總結：
-
-
MVC模式出現較早，主要應用在後端，如Spring MVC、Asp.NET MVC等，在前端領域的早期也有應用，如Backbone.js。它的優點是分層清晰，缺點是資料流混亂，靈活性帶來的維護性問題
-
MVP模式是在MVC的進化形式，Presenter作為中間層負責MV通訊，解決了兩者耦合問題，但P層過於臃腫會導致維護問題
-