摘要：從協(xié)作關(guān)系上講，很多前端開發(fā)團(tuán)隊(duì)每個(gè)成員的職責(zé)不是很清晰，有了前端的框架，這個(gè)狀況會(huì)大有改觀?？蚣艿睦砟钍前亚岸税凑章氊?zé)分層，每一層都相對(duì)比較獨(dú)立，有自己的價(jià)值，也有各自發(fā)揮的余地。

MV框架又是為什么興起的呢？它的出現(xiàn)，伴隨著一些 Web 產(chǎn)品逐漸往應(yīng)用方向發(fā)展，遇到了在 C/S 領(lǐng)域相同的問題：由于前端功能的增強(qiáng)、代碼的膨脹，導(dǎo)致不得不做“前端的架構(gòu)”這個(gè)事情了。經(jīng)常有人質(zhì)疑，在前端搞 MV有什么意義？也有人提出這樣的疑問：以 AngularJS，Knockout，BackBone 為代表的 MV*框架，它跟 jQuery 這樣的框架有什么區(qū)別？我 jQuery 用得好好的，有什么必要再引入這種框架？

回答這些問題之前，先要理清一些歷史，前端從什么時(shí)候開始有框架的？

早期前端都是比較簡(jiǎn)單，基本以頁(yè)面為工作單元，內(nèi)容以瀏覽型為主，也偶爾有簡(jiǎn)單的表單操作，
這個(gè)時(shí)期每個(gè)界面上只有很少的 JavaScript 邏輯，基本不太需要框架。隨著 AJAX 的出現(xiàn)，Web2.0的興起，人們可以在頁(yè)面上可以做比較復(fù)雜的事情了，然后前端框架才真正出現(xiàn)了，以 jQuery 為代表，針對(duì)界面上常見的 DOM 操作，遠(yuǎn)程請(qǐng)求，數(shù)據(jù)處理等作了封裝，也有專注于處理數(shù)據(jù)的Underscore，嚴(yán)格來說，這些都不能算框架，而是算庫(kù)。

庫(kù)和框架是有一些區(qū)別的：庫(kù)是一種工具，我提供了，你可以不用，即使你用了，也沒影響你自
己的代碼結(jié)構(gòu)?？蚣軇t是面向一個(gè)領(lǐng)域，提供一套解決方案，如果你用我，就得按照我的方式辦事。

按照這個(gè)定義，jQuery 和 Underscore 都只能算是庫(kù)，ExtJS 和 dojo 算框架。

MV*框架又是為什么興起的呢？它的出現(xiàn)，伴隨著一些 Web 產(chǎn)品逐漸往應(yīng)用方向發(fā)展，遇到了
在 C/S 領(lǐng)域相同的問題：由于前端功能的增強(qiáng)、代碼的膨脹，導(dǎo)致不得不做“前端的架構(gòu)”這個(gè)事情了。

很多做后端開發(fā)的人對(duì)前端架構(gòu)很不屑，認(rèn)為前端只是很薄的一層?xùn)|西，做架構(gòu)干什么？什么，
不但要搞架構(gòu)，還要搞 MVC？Java Struts 的 MVC 中，整個(gè)前端都只能算是 View 而已，你還要在這個(gè) View 里面劃分模型和控制器等其他東西？他們中的多數(shù)對(duì)這個(gè)很不屑，但 Web 前端隨著復(fù)雜度的增加，很多地方跟客戶端已經(jīng)沒有本質(zhì)區(qū)別了。

jQuery 的思維方式是：以 DOM 操作為中心

MV*框架的思維方式是：以模型為中心，DOM 操作只是附加

所以回到那個(gè)問題上，jQuery 滿足了你的業(yè)務(wù)需要，你還有什么必要引入 MV*框架？

這個(gè)是要看產(chǎn)品類型的，如果是頁(yè)面型產(chǎn)品，多數(shù)確實(shí)不太需要它，因?yàn)轫?yè)面中的 JavaScript
代碼，處理交互的絕對(duì)遠(yuǎn)遠(yuǎn)超過處理模型的，但是如果是應(yīng)用軟件類產(chǎn)品，這就太需要了。

長(zhǎng)期做某個(gè)行業(yè)軟件的公司，一般都會(huì)沉淀下來一些業(yè)務(wù)組件，主要體現(xiàn)在數(shù)據(jù)模型、業(yè)務(wù)規(guī)則
和業(yè)務(wù)流程，這些組件基本都存在于后端，在前端很少有相應(yīng)的組織。在以往的經(jīng)驗(yàn)里，他們是有做MVC 的，也嘗試做了一些界面組件，但做法比較過時(shí)，比如說使用 JSF 或者 GWT 這樣的方式。

JSF 的問題是什么？它的問題并不在于界面跟邏輯混合，所謂的縱向切分組件，Polymer 這種純前端框架也是這么切分的，它問題在于組件的生成和渲染不在同一個(gè)地方。所以，邏輯代碼的位置很尷尬，如果這個(gè)界面簡(jiǎn)單還好說，復(fù)雜起來就很麻煩了，就是很多明明是前端邏輯代碼，卻需要通過后端去生成。

GWT 這種方式相對(duì)要好一些，它的問題是留給 UI 調(diào)節(jié)的余地太小了，比較缺乏靈活性。

這類基于某種服務(wù)端技術(shù)的組件化方式有一些局限性，比如它較大程度限制了前端的發(fā)揮，在早
一些的時(shí)候，這種方式可能還不錯(cuò)，但是現(xiàn)在隨著時(shí)代發(fā)展，用戶對(duì)前端用戶體驗(yàn)要求越來越高，需要我們把很大一部分精力繼續(xù)放回前端來。JSF 等方案的另外一個(gè)問題是綁定了某種服務(wù)端環(huán)境，很難切換到另外一種后端上，如果碰上要用 Hybird 方式開發(fā)，想復(fù)用一些前端邏輯，幾乎毫無(wú)可能。

那么，我們看看純前端的框架，看看都是怎么解決這些問題的。以 Google 為例，它推出了兩個(gè)框架，Polymer 和 Angular，而且處于并行發(fā)展的階段，這兩者理念還有不小的差別，給不少人帶來了困惑。

Polymer 切分組件的方式有點(diǎn)類似 JSF，它跟 HTML5標(biāo)準(zhǔn)中的 Shadow DOM 和 Element 有很大聯(lián)系，這種切分組件的方式非常直觀，每個(gè)組件都是端到端的，包含 UI 和邏輯，直接放置到某個(gè)界面上就能用，這種方式很容易被業(yè)務(wù)開發(fā)人員接受，但里面的時(shí)序比較難處理。

比如說，有兩個(gè)組件，里面各包含一個(gè)下拉框，有數(shù)據(jù)的聯(lián)動(dòng)關(guān)系，因?yàn)樗鼈兲幵趦蓚€(gè)不同的組
件里，聯(lián)動(dòng)的處理代碼就很難寫，考慮到組件的特點(diǎn)，要盡量隱藏自己的內(nèi)部實(shí)現(xiàn)，所以從外部獲取組件內(nèi)部的某個(gè)元素要繞一層，而組件不能依賴其他外部的東西，所以到最后只有通過事件去實(shí)現(xiàn)，這個(gè)聯(lián)動(dòng)代碼寫好了應(yīng)當(dāng)放在哪里，也是個(gè)大問題。我們的例子僅僅是這么簡(jiǎn)單，就要繞這么個(gè)大圈子才能保證時(shí)序，如果場(chǎng)景比較復(fù)雜，非常難以控制。

如果同樣的組件在某個(gè)界面被復(fù)用多次，數(shù)據(jù)的一致性也很難保證，設(shè)想一下某個(gè)界面存在兩個(gè)
一樣的下拉框，分別處于不同組件中，兩者的數(shù)據(jù)都需要分別去加載，這個(gè)過程是有浪費(fèi)的，更嚴(yán)重的是，如果這個(gè)下拉框?qū)?yīng)的數(shù)據(jù)有更新，很難把每個(gè)實(shí)例都更新一遍，這個(gè)處理過程是非常麻煩的。

Angular 框架處理問題的方式跟它有所不同，它是水平分層，所有這些數(shù)據(jù)訪問邏輯都跟 UI 徹底分離，所以可以很輕松地把這個(gè)邏輯代碼寫出來，這么一來，前面所述端到端的組件就徹底退化，變成只有界面展現(xiàn)了。

看看剛才碰到的兩個(gè)問題，第一個(gè)，模型代碼按照業(yè)務(wù)領(lǐng)域進(jìn)行劃分，獲取的數(shù)據(jù)放在兩個(gè)不同
的數(shù)組，然后通過雙向綁定跟 UI 產(chǎn)生關(guān)聯(lián)，如果 UI 上一個(gè)下拉框選中項(xiàng)發(fā)生變更，只需要監(jiān)控這個(gè)取值項(xiàng)，然后更新另一個(gè)下拉框的取值列表即可，完全不需要繞彎子。即使這兩個(gè)處于不同模型中，也可以用類似后端的方式，采用事件總線等機(jī)制去完成通信。

第二個(gè)更簡(jiǎn)單了，復(fù)用的組件其實(shí)只有 UI，也就是說，只有 UI 是多實(shí)例的，模型其實(shí)只有一份，比如說一個(gè)地區(qū)的樹形結(jié)構(gòu)，即使一個(gè)界面上同時(shí)有維護(hù)和使用兩種功能，都可以共享同一份模型，當(dāng)維護(hù)這邊對(duì)數(shù)據(jù)進(jìn)行了更新，就實(shí)時(shí)反饋到模型中，然后由雙向綁定再把這個(gè)模型同步到界面上的使用方去，整個(gè)過程清晰可控。

從協(xié)作關(guān)系上講，很多前端開發(fā)團(tuán)隊(duì)每個(gè)成員的職責(zé)不是很清晰，有了前端的 MV框架，這個(gè)
狀況會(huì)大有改觀。MV框架的理念是把前端按照職責(zé)分層，每一層都相對(duì)比較獨(dú)立，有自己的價(jià)值，也有各自發(fā)揮的余地。

為什么多數(shù)做互聯(lián)網(wǎng)前端開發(fā)的同學(xué)們感受不到 MV*框架的重要性呢，因?yàn)樵谶@個(gè)協(xié)作體系里，
Model 的這一塊不夠復(fù)雜，在傳統(tǒng)軟件領(lǐng)域，Model 的部分是代碼最多的，View 的相對(duì)少一些，而互聯(lián)網(wǎng)領(lǐng)域里，基本是相反的，所以 Model 這塊淪為附加，如果主要在操作 View 和 Controller，那當(dāng)然 jQuery 這類框架比較好用了。

所以，經(jīng)?？吹接谢ヂ?lián)網(wǎng)產(chǎn)品的同學(xué)們講前端 MVC，但舉例的時(shí)候，都比較牽強(qiáng)，很多時(shí)候，
他們舉出來的那個(gè) Model，其實(shí)都不能算真正的 Model，而是在操作 View 的過程中一些輔助的模型，真正的 Model 是貫穿前后端的。

歸根結(jié)底，前端 MV*框架帶來的是一整套工作流程的變更，后端工程師也可以編寫前端的模型
代碼，把它跟后端徹底打通，交互工程師處理 UI 跟模型的互動(dòng)關(guān)系，UI 工作人員可以專注、無(wú)障礙地處理 HTML 源碼，把它們以界面模版的形式提供給交互工程師。這一整套協(xié)作機(jī)制能夠大大提高B/S 架構(gòu)系統(tǒng)的開發(fā)效率，如果再有外圍的管控平臺(tái)，生產(chǎn)效率將真正踏進(jìn)工業(yè)化的階段。

到這個(gè)階段，前端開發(fā)人員的出路是什么呢？我認(rèn)為有兩種。拿服裝行業(yè)來對(duì)比，如果你要的是普通的，就使用工業(yè)手段批量生產(chǎn)，使用 MV*框架，做好架構(gòu)和組件重用，做得快，細(xì)節(jié)不是很講究。如果你想要更好的，有特色的，就需要名家設(shè)計(jì)，手工打造，非常精巧，高端大氣上檔次。所以，這也就代表著前端開發(fā)的兩種發(fā)展方向。

摘自：web 開發(fā)者

  
分享來自：https://d.bianzhifu.com/pdf/