前言
前端框架的變遷饥伊，體系架構(gòu)的完善象浑，使得我們只知道框架，卻不明白它背后的道理撵渡。我們應(yīng)該抱著一顆好奇心融柬，在探索框架模式的變遷過程中，體會(huì)前人的一些理解和思考
本篇將講述的是前端框架變化過程中的一些思考趋距，前端框架模式的變化：從無到有粒氧，從MVC(Flux或者Redux)->MVP->MVVM。這段變化的過程节腐，會(huì)讓人不斷琢磨外盯，每次的變化摘盆，都是一次大的進(jìn)步。現(xiàn)在在前端的框架都是MVVM的模式饱苟，還有像Flux和Redux之類的MVC變種——獨(dú)特的單向數(shù)據(jù)流框架孩擂。如果你喜歡我的文章，歡迎評論箱熬，歡迎Star~类垦。歡迎關(guān)注我的github博客
正文
其實(shí)，這些框架模式我們平時(shí)都會(huì)有所接觸城须。它遵循著將整體應(yīng)用的功能塊進(jìn)行分離的原則蚤认，對開發(fā)者開發(fā)軟件進(jìn)行一定的規(guī)范，以保持系統(tǒng)的穩(wěn)定以及可維護(hù)性糕伐。
講述前端框架變遷的過程中砰琢，我們可以通過梳理最近幾十年的前端發(fā)展時(shí)間線，來深入分析前端的從無到有良瞧，從有到優(yōu)的過程陪汽。
最初的時(shí)代
最初的時(shí)代，應(yīng)該是web1.0時(shí)代吧褥蚯。當(dāng)時(shí)挚冤，開發(fā)者們并沒有前端的概念。開發(fā)一個(gè)應(yīng)用遵岩，或許只要5個(gè)人的小團(tuán)隊(duì)你辣，就能夠很快的配置出可運(yùn)行的環(huán)境。而開發(fā)的語言使用的也是最初的JSP尘执、ASP和PHP。拿JSP舉例的話宴凉，當(dāng)時(shí)系統(tǒng)的整體架構(gòu)圖可能是這樣子的：
記得在學(xué)校的時(shí)候誊锭，最早搭建系統(tǒng)就是使用的這種架構(gòu)。
這種架構(gòu)的好處是簡單快捷弥锄。使用Eclipse+tomcat就可以之間把程序跑起來丧靡，以及jsp的強(qiáng)大功能，足夠滿足小應(yīng)用的開發(fā)籽暇。
但是温治，同樣缺點(diǎn)也非常明顯：
業(yè)務(wù)體系增大，調(diào)試?yán)щy：隨著業(yè)務(wù)體系的增大戒悠，后臺(tái)service也會(huì)逐步膨脹熬荆，大致需要建設(shè)一個(gè)開發(fā)服務(wù)器進(jìn)行存放，這會(huì)導(dǎo)致一個(gè)問題就是前端無法在本地進(jìn)行調(diào)試绸狐，每次進(jìn)行修改之后卤恳，都必須上傳到開發(fā)服務(wù)器進(jìn)行測試（況且開發(fā)服務(wù)器可能本身就不穩(wěn)定）累盗。
JSP代碼難以維護(hù)：或許人少的時(shí)候，學(xué)JSP挺簡單的突琳。但是若债，一旦團(tuán)隊(duì)人數(shù)增多，JSP內(nèi)參雜的業(yè)務(wù)邏輯也會(huì)逐漸增加拆融，這會(huì)導(dǎo)致的是JSP本身難以維護(hù)蠢琳。
為了讓開發(fā)更加的便捷，代碼變得更加的可維護(hù)镜豹，同時(shí)使得前后端的職責(zé)加以分離傲须。這時(shí)，我們或許會(huì)考慮改變一下開發(fā)模式逛艰，將后端MVC化躏碳，而前端的展示則以模板的形式進(jìn)行嵌套。典型的框架就是Spring散怖、Structs菇绵。整體的框架，如圖所示：
使用這樣子的架構(gòu)镇眷，復(fù)雜度被降低了咬最，職責(zé)也會(huì)比較清晰。這個(gè)時(shí)代被稱為后端的MVC時(shí)代欠动。這個(gè)時(shí)候永乌，前后端開始形成了一定的分離。前端只需要在本地編寫好相應(yīng)的頁面具伍，然后交給后端開發(fā)的人翅雏，讓他們可以根據(jù)模板進(jìn)行一個(gè)嵌套。這是前端只完成了后端開發(fā)中的view層內(nèi)容人芽。淘寶的早期使用的就是這種模式⊥福現(xiàn)在仍有小部分創(chuàng)業(yè)型的公司會(huì)使用這種方式進(jìn)行開發(fā)，主要是節(jié)約用人成本萤厅。
但是橄抹，同樣的這種模式存在著一些：
前端頁面開發(fā)效率不高：其實(shí)，早期的時(shí)候根本也沒啥前端開發(fā)工程師惕味，有的只是頁面仔楼誓。更多公司可能也有后端的人使用js在寫頁面的。因此名挥，問題就暴露了出來疟羹，前端所做出來的頁面需要放到后端環(huán)境去運(yùn)行，使得前端開發(fā)的效率并不是特別之高，因?yàn)閷τ诤蠖谁h(huán)境的依賴程度比較大阁猜。
前后端職責(zé)不清：由于前端并未做太多的工作丸逸，以至于后端的開發(fā)體量比較龐大。就拿路由管理來舉例子剃袍，本來路由管理可以由前端開發(fā)的人員來進(jìn)行開發(fā)和管理黄刚。但是，使用這種架構(gòu)時(shí)民效，后端需要去維護(hù)一個(gè)龐大的路由表憔维，增加了后端的開發(fā)量。
前端的第一個(gè)春天
有個(gè)東西帶來了前端的第一個(gè)春天——AJAX畏邢。自從Gmail的出現(xiàn)业扒，ajax技術(shù)開始風(fēng)靡全球。許多公司和開發(fā)者都不斷地利用它做實(shí)驗(yàn)舒萎。有了ajax之后程储，前后端的職責(zé)就更加的清晰了。因?yàn)榍岸丝梢酝ㄟ^Ajax與后端進(jìn)行數(shù)據(jù)交互臂寝，因此章鲤，整體的架構(gòu)圖也變化成了下面這幅圖：
通過ajax與后臺(tái)服務(wù)器進(jìn)行數(shù)據(jù)的交換，前端開發(fā)的人員咆贬，只需要開發(fā)自己頁面這部分的內(nèi)容败徊，數(shù)據(jù)可由后臺(tái)進(jìn)行提供。而且ajax可以使得頁面實(shí)現(xiàn)部分刷新掏缎，極大的減少了之前需要反復(fù)開發(fā)的頁面皱蹦。這時(shí)，才開始有前端工程師開始慢慢從事前端眷蜈。同時(shí)前端的類庫也慢慢的開始發(fā)展沪哺，最著名的就是jQuery了。
但其實(shí)酌儒，這樣子的架構(gòu)中還是存在一定的問題——前端缺乏一種可行的開發(fā)模式凤粗。整體的內(nèi)容都雜糅在一起，一旦應(yīng)用增大今豆，就會(huì)導(dǎo)致難以維護(hù)了。舉個(gè)例子柔袁，當(dāng)圖書少的時(shí)候呆躲，我們就算隨意放置，整理起來都比較方便捶索；但是插掂，一旦具有像圖書館一樣多的圖書時(shí)，必須有一種統(tǒng)一的管理方式。同樣的辅甥，前后端分離之后酝润，前端的開發(fā)業(yè)務(wù)逐漸增多，責(zé)任也愈加的巨大璃弄，開發(fā)者急需一種比較好的框架來規(guī)范整個(gè)應(yīng)用要销。因此，前端的MVC也隨之而來夏块。
前后端分離后的架構(gòu)演變——MVC疏咐、MVP和MVVM
MVC
前端的MVC應(yīng)該與后端類似，具備著View脐供、Controller和Model浑塞。
Model：負(fù)責(zé)保存應(yīng)用數(shù)據(jù)，與后端數(shù)據(jù)進(jìn)行同步
Controller：負(fù)責(zé)業(yè)務(wù)邏輯政己，根據(jù)用戶行為對Model數(shù)據(jù)進(jìn)行修改
View：負(fù)責(zé)視圖展示酌壕，將model中的數(shù)據(jù)可視化出來。
理論上歇由，他們?nèi)咝纬闪艘粋€(gè)如圖所示的模型：
這樣的模型卵牍，在理論上是可行的。但往往在實(shí)際開發(fā)中印蓖，并不會(huì)這樣去操作辽慕。因?yàn)殚_發(fā)的過程需要靈活，而這種模式并不滿足靈活的條件赦肃。例如溅蛉，一個(gè)小小的事件操作，都必須經(jīng)過這樣的一個(gè)流程他宛，那么開發(fā)就不再便捷了船侧。
在實(shí)際場景中，我們往往會(huì)看到另一種模式厅各，如圖：
這種模式在開發(fā)中更加的靈活镜撩，backbone.js框架就是這種的模式。
但是队塘，這種靈活袁梗，也會(huì)導(dǎo)致一些嚴(yán)重的問題：
- 數(shù)據(jù)流混亂°竟牛或許遮怜，你還不一定能夠很好的理解，何為數(shù)據(jù)流混亂鸿市。那么锯梁，我們來看一副圖：
這幅圖中即碗，特別是model和view這一塊的數(shù)據(jù)交互，感覺看起來像是連連看陌凳，非常的混亂剥懒，而且維護(hù)起來非常麻煩。這就是靈活開發(fā)帶來的后遺癥合敦。拿backbone舉個(gè)例子初橘，backbone將Model的set和on方法暴露出來，方便外部對其進(jìn)行直接操作蛤肌。
- View比較龐大壁却，而Controller比較單薄：由于很多的開發(fā)者都會(huì)在view中寫一些邏輯代碼，逐漸的就導(dǎo)致view中的內(nèi)容越來越龐大裸准，而controller變得越來越單薄展东。
既然有缺陷，就會(huì)有變革炒俱。前端的變化中盐肃，好像少了MVP的這種模式，或許是因?yàn)锳ngular早早地將MVVM的框架模式帶入了前端权悟，這也許就是Google工程師的智慧吧砸王。那我們還是需要來了解一下MVP這種模式，雖然前端開發(fā)并不常用峦阁，但是在安卓等native開發(fā)時(shí)谦铃，開發(fā)者都會(huì)考慮到它的。
MVP
MVP與MVC很接近榔昔，P指的是Presenter驹闰，presenter可以理解為一個(gè)中間人，它負(fù)責(zé)著View和Model之間的數(shù)據(jù)流動(dòng)撒会，防止View和Model之間直接交流嘹朗。我們可以看一下圖示：
我們可以通過看到，presenter負(fù)責(zé)和Model進(jìn)行雙向交互诵肛，還和View進(jìn)行雙向交互屹培。這種交互方式，相對于MVC來說少了一些靈活怔檩，VIew變成了被動(dòng)視圖褪秀，并且本身變得很小。雖然它分離了View和Model薛训。但是應(yīng)用逐漸變大之后溜歪，缺陷也會(huì)隨之暴露。
缺陷：
由于大部分邏輯都需要presenter去進(jìn)行管理许蓖，從而導(dǎo)致presenter的體積增大，難以維護(hù)。如果需要去解決這個(gè)問題膊爪，或許可以從MVVM的思想中找到答案自阱。
MVVM
首先，何為MVVM呢米酬？MVVM可以分解成(Model-View-VIewModel)沛豌。ViewModel可以理解為在presenter基礎(chǔ)上的進(jìn)階版。廢話不多說赃额，先上圖例：
在這里View是ViewModel的外在顯示加派，和ViewModel的數(shù)據(jù)是同步的。一旦View中的數(shù)據(jù)發(fā)生變化跳芳，會(huì)自動(dòng)同步到ViewModel芍锦，然后ViewModel可以將變化的數(shù)據(jù)傳給Model；反過來也是一樣的飞盆，Model中的數(shù)據(jù)一旦發(fā)生改變娄琉，就會(huì)將值傳給ViewModel，而ViewModel也會(huì)同步更新到view中∠判現(xiàn)在的框架實(shí)現(xiàn)這樣的形式孽水，各有各的不同。主要的三個(gè)框架angular2城看、vue女气、react都是實(shí)現(xiàn)了這樣子的模式。
這種的好處就是View和Model之間被分離開來测柠。view不知道m(xù)odel的存在炼鞠，viewmodel和model也覺察不到view。事實(shí)上鹃愤，model也完全忽略viewmodel和view的存在簇搅。這是一個(gè)非常松散耦合的設(shè)計(jì)。
但它也不是所用地方都適用的软吐，例如瘩将，后端開發(fā)是適用的。因?yàn)榫W(wǎng)絡(luò)資源成本過高凹耙，開發(fā)成本過高導(dǎo)致的姿现。
Flux或者Redux
討論完上面的三種框架，我們再來看一下Flux肖抱。之前备典，我們在討論MVC的時(shí)候，提及過MVC最主要的缺點(diǎn)就是數(shù)據(jù)流混亂意述，難以管理提佣。但是吮蛹，F(xiàn)acebook卻在這個(gè)基礎(chǔ)上對MVC做出了改變，那就是——單向數(shù)據(jù)流拌屏。只要將數(shù)據(jù)流進(jìn)行規(guī)范潮针，那么原來的模式還是大有可為的。
我們可以來看一下倚喂，F(xiàn)lux框架的圖示：
從圖中每篷，我們可以看到形成了一條Action到Dispatcher，再到Store端圈，之后是View的焦读，一條單向數(shù)據(jù)流。在這里Dispatcher會(huì)嚴(yán)格限行我們操作數(shù)據(jù)的行為舱权，而Store也不會(huì)暴露setter接口矗晃，讓其隨意被修改。最終刑巧，這樣的一套框架在大多數(shù)場景下喧兄，比MVC更加完美。（細(xì)節(jié)部分我們不做探究啊楚，有興趣可以研究一下Redux源碼吠冤，也就近千行代碼）。
總結(jié)
我們依據(jù)前端發(fā)展為時(shí)間線恭理，整理了前端整體框架的從無到有拯辙，從有到優(yōu)的過程。
- 最初的時(shí)代——web1.0
- 前端的春天——Ajax
- 前端的框架——MVC颜价、MVP涯保、MVVM
- MVC 的變種——FLux
希望這些能夠幫你理解現(xiàn)在的前端，理解框架之間的卓越點(diǎn)周伦。同時(shí)也希望大家一起進(jìn)步夕春，一起成長。
如果你對我寫的有疑問专挪，可以評論及志，如我寫的有錯(cuò)誤，歡迎指正寨腔。你喜歡我的博客速侈，請給我關(guān)注Star~呦。大家一起總結(jié)一起進(jìn)步迫卢。歡迎關(guān)注我的github博客
