Web技術的前世此生（三）

前言：我是JavaScript，若是你還不認識我，不妨先看看《 Web技術的前世此生（一）》，以及《 Web技術的前世此生（二）》

前面我提過，個人大哥HTML有一個叫PHP的死黨，這傢伙有事沒事常常上咱們家串門。

這天，PHP又來找我大哥閒扯。

「老哥，你知道一個叫Ruby的傢伙嗎？」PHP問道。

「知道啊，最近咱們合做過好幾個項目呢。怎麼想起問它了？」

「呀，你是不清楚，這小子最近在咱們那可火了，據說是鼓搗了一個什麼架子。」PHP繼續說道。

「喔，你是說Rails啊，」很明顯，大哥對PHP口中的「架子」很熟悉，向PHP解釋道：「那不是架子，是Ruby用來構建網站的框架。」

我在一旁聽着，藉機打趣道：「後端那幫傢伙有一個算一個，誰敢說開發網站有比咱PHP老兄還火的？」

「Js，你可別小看了這個Rails，」大哥做爲一個老實人，聽不出我在開玩笑，繼續一本正經的說：「以前PHP老弟的平易近人對客戶是挺有吸引力的，然而隨着他們的網站規模愈來愈大，PHP的親和力對於他們而言反而成了一種難以駕馭的負擔，彷佛他們更須要尋求的是一種約束。」

「哎呀，老哥，你說的太對了，」PHP忽然從凳子上跳起來，「最近好幾個老客戶都從我這撤了，據說跑去找Ruby那小子了。老哥你說，那小子到底是有什麼魔力？」

「它搞的Rails框架就是用來規範網站的開發行爲，明確你我之間的職責所在的。」大哥慢條斯理地說道。

「大哥，您就別賣關子了，趕忙給咱們講講這個Rails吧？」對這事我也來了興致。

「它對一個網站的架構劃分了三個層次。好比我就歸屬於只負責頁面展示的視圖層（View）；有關業務邏輯的活從視圖層剝離出來，由不一樣的模型（Model）去作；至於接受用戶的輸入交由恰當的Model去處理，處理完後再將數據傳遞給View，這個由控制器（controller）完成。」

大哥看着我迷茫的眼神，又繼續補充道：「對於一個動態網站而言，每個頁面應該長成什麼樣子是一件事，而究竟該呈現哪個頁面，以及頁面上動態變化的數據該是什麼又是另一件事。按以前PHP的作法，一個文件中既有咱們前端用來佈局頁面的代碼，又混雜着它用來處理業務邏輯的代碼，先不說設計上是否合理，首先這就得要求使用者既要熟悉咱們前端，還要熟悉後端，」大哥一邊解釋着一邊朝我詭祕的一笑：「Js，你有興趣瞭解下PHP每次上工都是如何幹活的嗎？」

」別別別，」我趕忙搖頭，「每次我連本身的活都幹不完，哪有工夫搭理它啊。」

PHP在一旁聽着不樂意了，」去你的，我還煩你老在我眼前晃悠呢。「

「這就對了！Rails的出現就解決了這個問題，咱們前端的工做就只是套用所謂的模板引擎來作頁面的展示，管它Ruby操做數據庫也好、作邏輯運算也罷，都通通和我們無關，咱們只須要拿到它最終處理過的數據填充到模板引擎裏，再給客戶展現出來就好了。」

「呃⋯⋯老哥，你這說的是否是所謂的MVC模式啊？我聽個人Java老大提起過。」PHP問道。

「沒錯，就是MVC，Java很早之前就玩這個了，它有一個相似的框架叫structs，只是以前這種開發模式還不流行，最近被Rails炒起來了。對了，我聽Java說它的structs也要升級到二代了，估計出來也會火一把吧。「

「哈哈，PHP，看來大家後端的小夥伴們都在搞框架，就你落伍了哦⋯⋯」，我又開始拿PHP開涮，「誒？PHP這傢伙人呢？PHP⋯⋯」轉過頭才發現它已經跑出很遠了，看來用不了多久關於PHP的MVC框架也會問世了。

（猿知原味注：隨着Ruby on Rails的流行，2007年以後的五年，進入到了Web後端發展史上一段框架橫飛的年代。框架的做用除了上面提到的展示層和業務邏輯層的解耦，還提供了諸如經過對象操做數據庫的ORM技術，以及URI路由、表單驗證、國際化、安全防禦等網站開發中的經常使用功能。在這期間也出現了一大批優秀的Web框架，譬如SSH（Struts+Spring+Hibernate）、SpringMVC、Rails、ASP.NET MVC、Django、Flask、CodeIgniter、Yii、Lavarel、Beego⋯⋯並且還遠遠不止這些。）

時間來到了2010年，在那先後發生了兩件事讓我印象深入。

一是咱們的不少客戶開始把本來在Web上提供的服務同時搬到智能手機上去，然而移動應用並不認識後端返回的Web頁面（猿知原味注：關於這一點，不包括近幾年興起的Web App和Hybrid App），這就迫使哪怕業務徹底相同的應用，針對Web端和移動端也得去開發並維護兩套後端代碼。

二是貪婪的人類對在後端的View層渲染頁面仍是不滿意，他們以爲咱們前端就不應和後端摻和到一塊去，但願將咱們完全分開。

之因此這兩件事讓我記憶猶新，是由於最終解決它們是我起了大做用。還記得我異步刷新網頁的能力嗎（Ajax）？既然人類討厭在後端作頁面渲染，那徹底能夠經過Ajax將數據拿到前端來渲染。這樣一來，一方面作到了先後端分離，糾結的人類沒必要再爲該由誰負責模板引擎而苦惱了；另外一方面，咱們前端和移動端一致決定讓一個叫JSON的傢伙當咱們的聯合運輸大隊長，由它來負責後端數據的傳輸工做，這樣對於相同的業務，後端只須要維護一套代碼就夠了。

「With great power comes great responsibility」，彼得叔叔對蜘蛛俠說的一句話讓我感同身受。自從我把頁面渲染的活攬到前端來以後，後端那幫哥們算是解脫了，然而我肩上的擔子迅速變沉了，天天忙的不可開交。

這種狀況持續了一兩年，直到有一天，個人好大哥提醒了我。

「Js，你看啊，不少年前咱們前端的職責就只是作頁面的展現，但Web發展到今天，咱們也和數據打上了交道。你這邊不只要發數據、收數據，還要處理數據，最後還要經過操做dom將數據更新到頁面上。」

HTML大哥接着說：「你是否是加粗文字能夠借鑑當初後端那幫小子搞的MVC框架，也鼓搗個什麼框架出來，方便我們前端將數據的活和視圖的活分開來幹？」

我一拍大腿，「對啊！如今的情況確實太凌亂了。咱們也能夠搞個View層只負責頁面渲染，搞個Model層專門處理數據模型，」我想了想接着說：「再經過某種方式將這兩層關聯起來，Model數據改變的時候同步到View顯示出來，View上的改變也能將數據同步回Model。」

「你說的這不就是雙向綁定嘛，」大哥給個人設想下了個定義，「還記得咱們有個叫Microsoft的客戶嗎？它在數據綁定這一塊頗有經驗，你能夠去找它討教討教。」

（猿知原味注：MVVM模式最先就是被微軟的WPF和Silverlight的架構師John Gossman提出來的）

沒過多久，像AngularJS、KnockoutJS、EmberJs、VueJS等一系列MV*模式的前端框架就相繼出現了。自此，我又過上了輕鬆愉快的美好生活。

故事讀完了，仍是意猶未盡？不要緊，關注「猿知原味」公衆號（yz--yw），還有一大波生動有趣的乾貨等着你。

傳送門：《Web技術的前世此生（一）》《Web技術的前世此生（二）》