web1.0時代
在web1.0時代并沒有前端的概念，開發(fā)一個web應用多數(shù)采用ASP.NET/Java/PHP編寫汁讼，項目通常有多個aspx/jsp/php文件構(gòu)成淆攻，每個文件中同時包含了HTML、CSS嘿架、Javascript瓶珊、C#/Java/PHP代碼，系統(tǒng)整體架構(gòu)可能是這個樣子：
這種架構(gòu)的好處是簡單快捷耸彪，但是缺點也非常明顯：JSP代碼難以維護
為了讓開發(fā)更加快捷伞芹，代碼更易維護，前后端職責更清晰蝉娜。便衍生出MVC開發(fā)模式和框架唱较，前端展示以模版的形式出現(xiàn)。典型的框架就是Spring召川、Structs南缓、Hibernte。整體框架如圖所示：
使用這種分層結(jié)構(gòu)荧呐，職責清晰西乖，代碼易維護。但這里的MVC僅限于后端坛增，前后端形成了一定的分離获雕，前端只完成了后端開發(fā)中的view層。
但是收捣，同樣的這種模式存在著一些：
1.前端頁面開發(fā)效率不高
2.前后端職責不清
web2.0時代
自從Gmail的出現(xiàn)届案，ajax技術(shù)開始風靡全球，有了ajax之后罢艾，前后端的職責就更加清晰了楣颠，因為前端可以通過ajax與后端進行數(shù)據(jù)交互，因此咐蚯，整體的架構(gòu)圖也變化成了下面這幅圖：
通過ajax與后臺服務(wù)器進行數(shù)據(jù)交互童漩，前端開發(fā)人員，只需要開發(fā)頁面這部分內(nèi)容，數(shù)據(jù)可由后臺進行提供。而且ajax可以使得頁面實現(xiàn)部分刷新翅娶，減少了服務(wù)端負載和流量消耗等限，用戶體驗也更佳。這時制市，才開始有專職的前端工程師示损。同時前端的類庫也開始慢慢的發(fā)展朗和，最著名的就是JQuery了馁痴。
當然此架構(gòu)也存在問題：缺乏可行的開發(fā)模式承載更復雜的業(yè)務(wù)需求谊娇，頁面內(nèi)容都糅雜在一起，一旦應用規(guī)模增大罗晕，就會導致難以維護了济欢。因此前端的MVC也隨之而來。
前后端分離的架構(gòu)演變 -- MVC小渊、MVP和MVVM
MVC
前端的MVC與后端類似船逮，具備著View，Controller和Model粤铭。
Model：負責保存應用數(shù)據(jù)，與后端數(shù)據(jù)進行同步
Controller：負責業(yè)務(wù)邏輯杂靶，根據(jù)用戶行為對Model數(shù)據(jù)進行修改
View：負責視圖展示梆惯，將Model中的數(shù)據(jù)可視化出來
三者形成了一個如圖所示的模型：
這樣的模型，在理論上是可行的吗垮。但往往在實際開發(fā)中垛吗，并不會這樣操作。因為開發(fā)過程并不靈活烁登。例如怯屉，一個小小的事件操作，都必須經(jīng)過這樣一個流程饵沧，那么開發(fā)就不在便捷了锨络。
在實際場景中，我們往往會看到另一種模式狼牺，如圖：
這種模式在開發(fā)中更加靈活羡儿，backbone.js框架就是這種模式。
但是是钥，這種靈活可能導致嚴重的問題：
1.數(shù)據(jù)流混亂掠归。如下圖：
2.view比較龐大，而controller比較單鼻哪唷：由于很多的開發(fā)者都會在view中寫一些邏輯代碼虏冻，逐漸就導致view中的代碼越來越龐大，而controller變的越來越單薄弹囚。
既然有缺陷厨相，就會有變革。前端的變化中似乎少了MVP這種模式，是因為angular早早的將MVVM這種模式帶入了前端领铐。MVP模式雖然前端開發(fā)并不常見悯森，但是在安卓等原生開發(fā)中，開發(fā)者還是會考慮到它绪撵。
MVP
MVP與MVC很接近瓢姻，P指的是Presenter，Presenter可以理解為一個中間人音诈，它負責這View和Model之間的數(shù)據(jù)流動幻碱，防止View和Model之間的直接交流。我們可以看下圖示：
我們可以通過看到细溅，presenter負責和Model進行雙向交互褥傍，還和View進行雙向交互，相對于MVC來說喇聊，少了一些靈活恍风，View變成了被動視圖，并且本身變得很小誓篱，雖然它分離了View和Model朋贬。但是應用逐漸變大之后，導致presenter的體積增大窜骄，難以維護锦募。要解決這個問題，或許可以從MVVM的思想中找到答案邻遏。
MVVM
首先糠亩，何為MVVM呢？MVVM可以分解成為（Model-View-ViewModel）准验∈晗撸可以理解為在presenter上的進階版。如圖所示：
ViewModel通過實現(xiàn)一套數(shù)據(jù)響應式機制自動響應Model中數(shù)據(jù)變化糊饱；
同時ViewModel會實現(xiàn)一套更新策略自動將數(shù)據(jù)變化轉(zhuǎn)換為視圖更新氛驮；
通過事件監(jiān)聽響應View中用戶交互修改Model中數(shù)據(jù)。
這樣在ViewModel中就減少了大量DOM操作代碼济似。
MVVM在保持View和Model松耦合的同時矫废，還減少了維護它們關(guān)系的代碼，使用戶專注于業(yè)務(wù)邏輯砰蠢，兼顧開發(fā)效率和可維護性蓖扑。
總結(jié)：
1.這三者都是框架模式，它們的設(shè)計目標都是為了解決Model和View的耦合問題台舱。
2.MVC模式出現(xiàn)較早主要應用在后端律杠，如Spring MVC潭流、ASP.NET MVC等，在前端領(lǐng)域的早期也有應用如backbone.js柜去。它的優(yōu)點是分層清晰灰嫉，缺點是數(shù)據(jù)流混亂，靈活性帶來的維護性問題嗓奢。
3.MVP模式在是MVC的進化形式presenter作為中間層負責MV通信讼撒，解決了兩者耦合問題，但P層過于臃腫導致維護問題股耽。
4.MVVM模式在前端領(lǐng)域有廣泛應用根盒，它不僅解決了MV耦合問題，還同時解決了維護兩者映射關(guān)系的大量繁雜代碼和DOM操作代碼物蝙，在提高開發(fā)效率炎滞，可讀性同時還保持了優(yōu)越的性能表現(xiàn)。
