資訊專欄INFORMATION COLUMN
摘要：從協作關系上講，很多前端開發團隊每個成員的職責不是很清晰，有了前端的框架，這個狀況會大有改觀。框架的理念是把前端按照職責分層，每一層都相對比較獨立，有自己的價值，也有各自發揮的余地。
簡介:
MV框架又是為什么興起的呢？它的出現，伴隨著一些 Web 產品逐漸往應用方向發展，遇到了在 C/S 領域相同的問題：由于前端功能的增強、代碼的膨脹，導致不得不做“前端的架構”這個事情了。經常有人質疑，在前端搞 MV有什么意義？也有人提出這樣的疑問：以 AngularJS，Knockout，BackBone 為代表的 MV*框架，它跟 jQuery 這樣的框架有什么區別？我 jQuery 用得好好的，有什么必要再引入這種框架？
歷史:回答這些問題之前，先要理清一些歷史，前端從什么時候開始有框架的？
早期前端都是比較簡單，基本以頁面為工作單元，內容以瀏覽型為主，也偶爾有簡單的表單操作，
這個時期每個界面上只有很少的 JavaScript 邏輯，基本不太需要框架。隨著 AJAX 的出現，Web2.0的興起，人們可以在頁面上可以做比較復雜的事情了，然后前端框架才真正出現了，以 jQuery 為代表，針對界面上常見的 DOM 操作，遠程請求，數據處理等作了封裝，也有專注于處理數據的Underscore，嚴格來說，這些都不能算框架，而是算庫。
庫和框架是有一些區別的：庫是一種工具，我提供了，你可以不用，即使你用了，也沒影響你自
己的代碼結構。框架則是面向一個領域，提供一套解決方案，如果你用我，就得按照我的方式辦事。
按照這個定義，jQuery 和 Underscore 都只能算是庫，ExtJS 和 dojo 算框架。
MV*框架又是為什么興起的呢？它的出現，伴隨著一些 Web 產品逐漸往應用方向發展，遇到了
在 C/S 領域相同的問題：由于前端功能的增強、代碼的膨脹，導致不得不做“前端的架構”這個事情了。
很多做后端開發的人對前端架構很不屑，認為前端只是很薄的一層東西，做架構干什么？什么，
不但要搞架構，還要搞 MVC？Java Struts 的 MVC 中，整個前端都只能算是 View 而已，你還要在這個 View 里面劃分模型和控制器等其他東西？他們中的多數對這個很不屑，但 Web 前端隨著復雜度的增加，很多地方跟客戶端已經沒有本質區別了。
jQuery 的思維方式是：以 DOM 操作為中心
MV*框架的思維方式是：以模型為中心，DOM 操作只是附加
為什么需要MV*框架？所以回到那個問題上，jQuery 滿足了你的業務需要，你還有什么必要引入 MV*框架？
這個是要看產品類型的，如果是頁面型產品，多數確實不太需要它，因為頁面中的 JavaScript
代碼，處理交互的絕對遠遠超過處理模型的，但是如果是應用軟件類產品，這就太需要了。
長期做某個行業軟件的公司，一般都會沉淀下來一些業務組件，主要體現在數據模型、業務規則
和業務流程，這些組件基本都存在于后端，在前端很少有相應的組織。在以往的經驗里，他們是有做MVC 的，也嘗試做了一些界面組件，但做法比較過時，比如說使用 JSF 或者 GWT 這樣的方式。
JSF 的問題是什么？它的問題并不在于界面跟邏輯混合，所謂的縱向切分組件，Polymer 這種純前端框架也是這么切分的，它問題在于組件的生成和渲染不在同一個地方。所以，邏輯代碼的位置很尷尬，如果這個界面簡單還好說，復雜起來就很麻煩了，就是很多明明是前端邏輯代碼，卻需要通過后端去生成。
GWT 這種方式相對要好一些，它的問題是留給 UI 調節的余地太小了，比較缺乏靈活性。
這類基于某種服務端技術的組件化方式有一些局限性，比如它較大程度限制了前端的發揮，在早
一些的時候，這種方式可能還不錯，但是現在隨著時代發展，用戶對前端用戶體驗要求越來越高，需要我們把很大一部分精力繼續放回前端來。JSF 等方案的另外一個問題是綁定了某種服務端環境，很難切換到另外一種后端上，如果碰上要用 Hybird 方式開發，想復用一些前端邏輯，幾乎毫無可能。
那么，我們看看純前端的框架，看看都是怎么解決這些問題的。以 Google 為例，它推出了兩個框架，Polymer 和 Angular，而且處于并行發展的階段，這兩者理念還有不小的差別，給不少人帶來了困惑。
Polymer 切分組件的方式有點類似 JSF，它跟 HTML5標準中的 Shadow DOM 和 Element 有很大聯系，這種切分組件的方式非常直觀，每個組件都是端到端的，包含 UI 和邏輯，直接放置到某個界面上就能用，這種方式很容易被業務開發人員接受，但里面的時序比較難處理。
比如說，有兩個組件，里面各包含一個下拉框，有數據的聯動關系，因為它們處在兩個不同的組
件里，聯動的處理代碼就很難寫，考慮到組件的特點，要盡量隱藏自己的內部實現，所以從外部獲取組件內部的某個元素要繞一層，而組件不能依賴其他外部的東西，所以到最后只有通過事件去實現，這個聯動代碼寫好了應當放在哪里，也是個大問題。我們的例子僅僅是這么簡單，就要繞這么個大圈子才能保證時序，如果場景比較復雜，非常難以控制。
如果同樣的組件在某個界面被復用多次，數據的一致性也很難保證，設想一下某個界面存在兩個
一樣的下拉框，分別處于不同組件中，兩者的數據都需要分別去加載，這個過程是有浪費的，更嚴重的是，如果這個下拉框對應的數據有更新，很難把每個實例都更新一遍，這個處理過程是非常麻煩的。
Angular 框架處理問題的方式跟它有所不同，它是水平分層，所有這些數據訪問邏輯都跟 UI 徹底分離，所以可以很輕松地把這個邏輯代碼寫出來，這么一來，前面所述端到端的組件就徹底退化，變成只有界面展現了。
看看剛才碰到的兩個問題，第一個，模型代碼按照業務領域進行劃分，獲取的數據放在兩個不同
的數組，然后通過雙向綁定跟 UI 產生關聯，如果 UI 上一個下拉框選中項發生變更，只需要監控這個取值項，然后更新另一個下拉框的取值列表即可，完全不需要繞彎子。即使這兩個處于不同模型中，也可以用類似后端的方式，采用事件總線等機制去完成通信。
第二個更簡單了，復用的組件其實只有 UI，也就是說，只有 UI 是多實例的，模型其實只有一份，比如說一個地區的樹形結構，即使一個界面上同時有維護和使用兩種功能，都可以共享同一份模型，當維護這邊對數據進行了更新，就實時反饋到模型中，然后由雙向綁定再把這個模型同步到界面上的使用方去，整個過程清晰可控。
從協作關系上講，很多前端開發團隊每個成員的職責不是很清晰，有了前端的 MV框架，這個
狀況會大有改觀。MV框架的理念是把前端按照職責分層，每一層都相對比較獨立，有自己的價值，也有各自發揮的余地。
為什么多數做互聯網前端開發的同學們感受不到 MV*框架的重要性呢，因為在這個協作體系里，
Model 的這一塊不夠復雜，在傳統軟件領域，Model 的部分是代碼最多的，View 的相對少一些，而互聯網領域里，基本是相反的，所以 Model 這塊淪為附加，如果主要在操作 View 和 Controller，那當然 jQuery 這類框架比較好用了。
所以，經常看到有互聯網產品的同學們講前端 MVC，但舉例的時候，都比較牽強，很多時候，
他們舉出來的那個 Model，其實都不能算真正的 Model，而是在操作 View 的過程中一些輔助的模型，真正的 Model 是貫穿前后端的。
歸根結底，前端 MV*框架帶來的是一整套工作流程的變更，后端工程師也可以編寫前端的模型
代碼，把它跟后端徹底打通，交互工程師處理 UI 跟模型的互動關系，UI 工作人員可以專注、無障礙地處理 HTML 源碼，把它們以界面模版的形式提供給交互工程師。這一整套協作機制能夠大大提高B/S 架構系統的開發效率，如果再有外圍的管控平臺，生產效率將真正踏進工業化的階段。
到這個階段，前端開發人員的出路是什么呢？我認為有兩種。拿服裝行業來對比，如果你要的是普通的，就使用工業手段批量生產，使用 MV*框架，做好架構和組件重用，做得快，細節不是很講究。如果你想要更好的，有特色的，就需要名家設計，手工打造，非常精巧，高端大氣上檔次。所以，這也就代表著前端開發的兩種發展方向。
摘自：web 開發者
分享來自：https://d.bianzhifu.com/pdf/
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/92328.html
摘要：事件訂閱發布者模式什么是讀音類似于是一套構建用戶界面的漸進式框架。與其他重量級框架不同的是，采用自底向上增量開發的設計。 MVC && MVVM 前端框架前端 MV*框架的意義 被誤解的MVC和被神化的MVVM Vue.js新手入門指南 單頁應用SPA的路由 單頁面應用的路由問題 本文是在自己總結時，看了許多篇文章有了些體會，然后把我認為有意義的摘抄下來，文中很大部分摘錄以上...
摘要：前端的工作更具有挑戰性，方向更多樣化假設我今年要入前端開發的坑這里強調前端是因為，現在很多，安卓開發加入大前端的這個稱呼。安卓版微信在截稿之前是大概的版本最新是并且持續了年不變，據說是為了穩定。 作者：Jay（滬江開發工程師）本文為原創文章，轉載請注明作者及出處 不好意思，沒有像其他公眾號一樣趕著發文章，每年到這個時候總有一大波什么今年前端預測，技術框架預測什么的。我這次寫這篇文針對的...
摘要：前端的工作更具有挑戰性，方向更多樣化假設我今年要入前端開發的坑這里強調前端是因為，現在很多，安卓開發加入大前端的這個稱呼。安卓版微信在截稿之前是大概的版本最新是并且持續了年不變，據說是為了穩定。 作者：Jay（滬江開發工程師）本文為原創文章，轉載請注明作者及出處 不好意思，沒有像其他公眾號一樣趕著發文章，每年到這個時候總有一大波什么今年前端預測，技術框架預測什么的。我這次寫這篇文針對的...
摘要：前端的工作更具有挑戰性，方向更多樣化假設我今年要入前端開發的坑這里強調前端是因為，現在很多，安卓開發加入大前端的這個稱呼。安卓版微信在截稿之前是大概的版本最新是并且持續了年不變，據說是為了穩定。 作者：Jay（滬江開發工程師）本文為原創文章，轉載請注明作者及出處 不好意思，沒有像其他公眾號一樣趕著發文章，每年到這個時候總有一大波什么今年前端預測，技術框架預測什么的。我這次寫這篇文針對的...
摘要：模式的目的是實現動態的程序設計，簡化程序后續的修改和擴展過程，并且使模塊能夠被重復利用。視圖的可視化表示，表示當前狀態的視圖。出現于年，最大變化在于代替了。其關鍵改進是數據綁定，也就是說，的數據狀態發生變化可以直接影響，反之亦然。 MV模式的目的是實現動態的程序設計，簡化程序后續的修改和擴展過程，并且使模塊能夠被重復利用。此模式通過簡化程序使之變得更為直觀。MV不是一種技術 ，而是一種...
閱讀 3384·2021-11-22 09:34
閱讀 656·2021-11-19 11:29
閱讀 1354·2019-08-30 15:43
閱讀 2235·2019-08-30 14:24
閱讀 1870·2019-08-29 17:31
閱讀 1228·2019-08-29 17:17
閱讀 2620·2019-08-29 15:38
閱讀 2736·2019-08-26 12:10
