前端框架模式的變遷

前言

前端框架的變遷，體系架構的完善，使得咱們只知道框架，卻不明白它背後的道理。咱們應該抱着一顆好奇心，在探索框架模式的變遷過程當中，體會前人的一些理解和思考

本篇將講述的是前端框架變化過程當中的一些思考，前端框架模式的變化：從無到有，從MVC(Flux或者Redux)->MVP->MVVM。這段變化的過程，會讓人不斷琢磨，每次的變化，都是一次大的進步。如今在前端的框架都是MVVM的模式，還有像Flux和Redux之類的MVC變種——獨特的單向數據流框架。若是你喜歡個人文章，歡迎評論，歡迎Star~。歡迎關注個人github博客

正文

其實，這些框架模式咱們平時都會有所接觸。它遵循着將總體應用的功能塊進行分離的原則，對開發者開發軟件進行必定的規範，以保持系統的穩定以及可維護性。

講述前端框架變遷的過程當中，咱們能夠經過梳理最近幾十年的前端發展時間線，來深刻分析前端的從無到有，從有到優的過程。

最初的時代

最初的時代，應該是web1.0時代吧。當時，開發者們並無前端的概念。開發一個應用，或許只要5我的的小團隊，就可以很快的配置出可運行的環境。而開發的語言使用的也是最初的JSP、ASP和PHP。拿JSP舉例的話，當時系統的總體架構圖多是這樣子的：

記得在學校的時候，最先搭建系統就是使用的這種架構。

這種架構的好處是簡單快捷。使用Eclipse+tomcat就能夠之間把程序跑起來，以及jsp的強大功能，足夠知足小應用的開發。

可是，一樣缺點也很是明顯：

1. 業務體系增大，調試困難：隨着業務體系的增大，後臺service也會逐步膨脹，大體須要建設一個開發服務器進行存放，這會致使一個問題就是前端沒法在本地進行調試，每次進行修改以後，都必須上傳到開發服務器進行測試（何況開發服務器可能自己就不穩定）。
2. JSP代碼難以維護：或許人少的時候，學JSP挺簡單的。可是，一旦團隊人數增多，JSP內參雜的業務邏輯也會逐漸增長，這會致使的是JSP自己難以維護。

爲了讓開發更加的便捷，代碼變得更加的可維護，同時使得先後端的職責加以分離。這時，咱們或許會考慮改變一下開發模式，將後端MVC化，而前端的展現則以模板的形式進行嵌套。典型的框架就是Spring、Structs。總體的框架，如圖所示：

使用這樣子的架構，複雜度被下降了，職責也會比較清晰。這個時代被稱爲後端的MVC時代。這個時候，先後端開始造成了必定的分離。前端只須要在本地編寫好相應的頁面，而後交給後端開發的人，讓他們能夠根據模板進行一個嵌套。這是前端只完成了後端開發中的view層內容。淘寶的早期使用的就是這種模式。如今仍有小部分創業型的公司會使用這種方式進行開發，主要是節約用人成本。

可是，一樣的這種模式存在着一些：

1. 前端頁面開發效率不高：其實，早期的時候根本也沒啥前端開發工程師，有的只是頁面仔。更多公司可能也有後端的人使用js在寫頁面的。所以，問題就暴露了出來，前端所作出來的頁面須要放到後端環境去運行，使得前端開發的效率並非特別之高，由於對於後端環境的依賴程度比較大。
2. 先後端職責不清：因爲前端並未作太多的工做，以致於後端的開發體量比較龐大。就拿路由管理來舉例子，原本路由管理能夠由前端開發的人員來進行開發和管理。可是，使用這種架構時，後端須要去維護一個龐大的路由表，增長了後端的開發量。

前端的第一個春天

有個東西帶來了前端的第一個春天——AJAX。自從Gmail的出現，ajax技術開始風靡全球。許多公司和開發者都不斷地利用它作實驗。有了ajax以後，先後端的職責就更加的清晰了。由於前端能夠經過Ajax與後端進行數據交互，所以，總體的架構圖也變化成了下面這幅圖：

經過ajax與後臺服務器進行數據的交換，前端開發的人員，只須要開發本身頁面這部分的內容，數據可由後臺進行提供。並且ajax可使得頁面實現部分刷新，極大的減小了以前須要反覆開發的頁面。這時，纔開始有前端工程師開始慢慢從事前端。同時前端的類庫也慢慢的開始發展，最著名的就是jQuery了。

但其實，這樣子的架構中仍是存在必定的問題——前端缺少一種可行的開發模式。總體的內容都雜糅在一塊兒，一旦應用增大，就會致使難以維護了。舉個例子，當圖書少的時候，咱們就算隨意放置，整理起來都比較方便；可是，一旦具備像圖書館同樣多的圖書時，必須有一種統一的管理方式。一樣的，先後端分離以後，前端的開發業務逐漸增多，責任也越發的巨大，開發者急需一種比較好的框架來規範整個應用。所以，前端的MVC也隨之而來。

先後端分離後的架構演變——MVC、MVP和MVVM

MVC

前端的MVC應該與後端相似，具有着View、Controller和Model。

Model：負責保存應用數據，與後端數據進行同步

Controller：負責業務邏輯，根據用戶行爲對Model數據進行修改

View：負責視圖展現，將model中的數據可視化出來。

理論上，他們三者造成了一個如圖所示的模型：

這樣的模型，在理論上是可行的。但每每在實際開發中，並不會這樣去操做。由於開發的過程須要靈活，而這種模式並不知足靈活的條件。例如，一個小小的事件操做，都必須通過這樣的一個流程，那麼開發就再也不便捷了。

在實際場景中，咱們每每會看到另外一種模式，如圖：

這種模式在開發中更加的靈活，backbone.js框架就是這種的模式。

可是，這種靈活，也會致使一些嚴重的問題：

1. 數據流混亂。或許，你還不必定可以很好的理解，何爲數據流混亂。那麼，咱們來看一副圖：

這幅圖中，特別是model和view這一塊的數據交互，感受看起來像是連連看，很是的混亂，並且維護起來很是麻煩。這就是靈活開發帶來的後遺症。拿backbone舉個例子，backbone將Model的set和on方法暴露出來，方便外部對其進行直接操做。

1. View比較龐大，而Controller比較單薄：因爲不少的開發者都會在view中寫一些邏輯代碼，逐漸的就致使view中的內容愈來愈龐大，而controller變得愈來愈單薄。

既然有缺陷，就會有變革。前端的變化中，好像少了MVP的這種模式，或許是由於Angular早早地將MVVM的框架模式帶入了前端，這也許就是Google工程師的智慧吧。那咱們仍是須要來了解一下MVP這種模式，雖然前端開發並不經常使用，可是在安卓等native開發時，開發者都會考慮到它的。

MVP

MVP與MVC很接近，P指的是Presenter，presenter能夠理解爲一箇中間人，它負責着View和Model之間的數據流動，防止View和Model之間直接交流。咱們能夠看一下圖示：

咱們能夠經過看到，presenter負責和Model進行雙向交互，還和View進行雙向交互。這種交互方式，相對於MVC來講少了一些靈活，VIew變成了被動視圖，而且自己變得很小。雖然它分離了View和Model。可是應用逐漸變大以後，缺陷也會隨之暴露。

缺陷：

因爲大部分邏輯都須要presenter去進行管理，從而致使presenter的體積增大，難以維護。若是須要去解決這個問題，或許能夠從MVVM的思想中找到答案。

MVVM

首先，何爲MVVM呢？MVVM能夠分解成(Model-View-VIewModel)。ViewModel能夠理解爲在presenter基礎上的進階版。廢話很少說，先上圖例：

在這裏View是ViewModel的外在顯示，和ViewModel的數據是同步的。一旦View中的數據發生變化，會自動同步到ViewModel，而後ViewModel能夠將變化的數據傳給Model；反過來也是同樣的，Model中的數據一旦發生改變，就會將值傳給ViewModel，而ViewModel也會同步更新到view中。如今的框架實現這樣的形式，各有各的不一樣。主要的三個框架angular二、vue、react都是實現了這樣子的模式。

這種的好處就是View和Model之間被分離開來。view不知道model的存在，viewmodel和model也覺察不到view。事實上，model也徹底忽略viewmodel和view的存在。這是一個很是鬆散耦合的設計。

但它也不是所用地方都適用的，例如，後端開發是適用的。由於網絡資源成本太高，開發成本太高致使的。

Flux或者Redux

討論完上面的三種框架，咱們再來看一下Flux。以前，咱們在討論MVC的時候，說起過MVC最主要的缺點就是數據流混亂，難以管理。可是，Facebook卻在這個基礎上對MVC作出了改變，那就是——單向數據流。只要將數據流進行規範，那麼原來的模式仍是大有可爲的。

咱們能夠來看一下，Flux框架的圖示：

從圖中，咱們能夠看到造成了一條Action到Dispatcher，再到Store，以後是View的，一條單向數據流。在這裏Dispatcher會嚴格限行咱們操做數據的行爲，而Store也不會暴露setter接口，讓其隨意被修改。最終，這樣的一套框架在大多數場景下，比MVC更加完美。（細節部分咱們不作探究，有興趣能夠研究一下Redux源碼，也就近千行代碼）。

總結

咱們依據前端發展爲時間線，整理了前端總體框架的從無到有，從有到優的過程。

1. 最初的時代——web1.0
2. 前端的春天——Ajax
3. 前端的框架——MVC、MVP、MVVM
4. MVC 的變種——FLux

但願這些可以幫你理解如今的前端，理解框架之間的卓越點。同時也但願你們一塊兒進步，一塊兒成長。

若是你對我寫的有疑問，能夠評論，如我寫的有錯誤，歡迎指正。你喜歡個人博客，請給我關注Star~呦。你們一塊兒總結一塊兒進步。歡迎關注個人github博客