前言
在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層過於臃腫會導致維護問題
-