網站靜態化處理—先後端分離—中（7）

　　上篇裏我講到了一種先後端分離方案，這套方案放到服務端開發人員面前比放在web前端開發人員面前或許獲得的掌聲會更多，我想不少資深前端工程師看到這樣的技術方案可能會有種說不出來的矛盾心情，當個人工做逐漸走向愈來愈專業化的前端開發後，我就時常被這套先後端分離方案所困惑，最近我終於明白了這個困惑的本源在哪裏了，那就是這套先後端分離方案實際上是服務端驅動的先後端分離方案，它的實現手段又是從服務端的MVC架構體系演化而來，所以該方案最大的問題就是它並無從根本上改變web前端從屬於服務端的被動局面。那麼問題來了，有沒有以web前端爲驅動的先後端分離方案呢，該方案能讓web前端的能力得到更大的釋放了？答案是絕對有。本篇就要講講以web前端驅動的先後端分離方案。

　　首先要提的就是javascriptMVC，下面我摘抄的是維基百科裏對javascriptMVC的解釋，具體以下：

　　首先是簡介：

JavaScriptMVC 是一套開放源代碼的多樣化互聯網應用程序框架，以 jQuery 與 OpenAJAX 爲基礎。JavaScriptMVC 利用 MVC 架構與工具擴展這些函式庫，以便開發與測試。因爲 JavaScriptMVC 不須要任何服務器端的配合，所以它能夠和任何的網站服務接口與編程語言整合，如 ASP.NET、Java、Perl、PHP、Python 或 Ruby。

 

　　接下來是歷史：

JavaScriptMVC 的第一個版本是在2008年5月釋出。穩定版的 JavaScriptMVC 2.0 在2009年6月釋出，並以 jQuery 爲基礎。主要開發目標爲維持程式碼的簡短和專一在它獨特的功能上。3.0版本在2010年12月釋出。而從 JavaScriptMVC 中所獨立出來的 MVC 架構「CanJS」則在2012年4月釋出。

　　從維基百科裏的解釋咱們會發現以下啓示，它們分別以下：

　　啓示一：javascriptMVC是一個應用框架的名字，這和jQuery的命名是同樣的，因此這裏我要聲明一下，本系列裏的javascriptMVC不是指代這個框架，而是指代的是使用javascript語言實現出的一類的web前端的MVC框架，本系列後面的javascriptMVC和前端MVC的含義是一致的。

　　啓示二：從javascriptMVC歷史裏咱們能夠看到初版的javascriptMVC產生於2008年，這個歷史要遠早於nodejs出現的時間，這說明了前端的MVC並非由於nodejs的出現而產生的，應該是nodejs推進了前端的MVC框架的應用和普及。

　　啓示三：維基百科裏有一段解釋：

因爲 JavaScriptMVC 不須要任何服務器端的配合，所以它能夠和任何的網站服務接口與編程語言整合，如 ASP.NET、Java、Perl、PHP、Python 或 Ruby。

 

　　這段話說明了前端MVC的一個很重要的特色就是前端MVC能夠擺脫服務端語言的束縛作到真正的獨立，同時前端MVC又能夠和任何服務端語言進行整合，你們能夠試想下若是咱們開發的web應用前端達到了前端MVC的程度，那麼公司在招聘web前端工程師的時候就不在會問你「你會java嗎？」或者「你會php嗎？」假如這個前端工程師所會的服務端語言能力和公司不匹配，面試官也不會再猶豫和搖頭了。

　　啓示三同時還隱含了一個問題，爲何好的前端MVC框架能夠作到和任何服務端語言配合呢？這個解決手段之一我在前文中的第一階段先後端分離方案裏就提到了，那就是解決報文格式的統一和交互接口的統一的技術手段，只有這樣前端MVC和服務端的靈活對接就不會再是問題了。可是僅僅這個手段仍是遠遠不夠的，咱們要達到這個需求還須要解決一個問題，這個問題就是要把服務端MVC霸佔web前端的工做也要搶回來。那如何搶呢？

　　上篇文章裏我分析過服務端MVC的視圖層的問題，服務端MVC的視圖層技術例如java裏的jsp技術，這個技術是將html和java代碼整合的技術，java的web容器把jsp解析完畢後最終生成爲html文件發送給瀏覽器，瀏覽器在解析這個html將最終效果展現給用戶。那麼咱們要搶回服務端霸佔的web前端的工做咱們就得分析下這些動態頁面技術到底作了哪些事情特別是侵佔web前端的事情。

　　這裏首先咱們要談談服務端在動態頁面裏的做用，其實服務端爲動態頁面做用很單一就是提供了網站須要展現的數據而已，服務端是不會創造一個新頁面的。服務端提供的數據的類型也是很統一，要不就是服務端語言提供的基本數據類型例如：字符、數字、日期等等，要不就是複雜點的數據類型例如數組、列表、鍵值對等等，不過歸屬服務端的動態頁面還須要服務端語言幫助作一件事情，那就是把服務端提供的數據整合到頁面裏，最終產生一個瀏覽器能夠解析的html網頁，這個操做無非就是使用服務端語言能夠構造文件的能力構建一個符合要求的html文件而已。不過一個頁面裏須要動態變化的每每只是其中一部分，因此作服務端的動態頁面開發時候咱們能夠直接寫html代碼，這些html代碼就等於在構造頁面展現的模板而已，而模板的空白處則是使用服務端數據填充，所以在java的web開發裏視圖層技術延生出了velocity，freemark這樣的技術，咱們將其稱之爲模板語言的由來。

　　因而可知，服務端MVC框架裏搶奪的web前端的工做就是搶佔了構建html模板的工做，那麼咱們在設計web前端的MVC框架時候對於和服務端對接這塊只須要讓服務端保持提供數據的特性便可。從這些論述裏咱們發現了，其實前端MVC框架要解決的核心問題應該有這兩個,它們分別是：

　　核心問題一：讓模板技術交由瀏覽器來作，讓服務端只提供單純的數據服務。

　　核心問題二：模板技術交由瀏覽器來承擔，那麼頁面的動態性體現也就是根據不一樣的服務端數據進行頁面部分刷新來完成的。

　　而這兩個核心問題解決辦法那就是使用ajax技術，ajax技術天生就符合解決這些問題的技術手段了。

　　要讓web前端承擔模板技術，就得使用javascript的模板技術，時下javascript的模板技術可謂是百花齊放，百家爭鳴，不少朋友曾爲這些技術稱奇，其實探求它的本源無非就是用javascript爲基礎實現了個jsp，velocity而已，若是有朋友還沒接觸過javascript模板技術，能夠在百度裏搜索下【javascript模板引擎】，本文這裏就不展開談論了。

　　前端的MVC討論到這裏又出現了一個新的疑問，我上面講到解決前端MVC兩大核心問題的手段是ajax技術，ajax是異步請求，那麼這是否是就是說讓網站所有使用異步請求咱們就能夠實現前端MVC，而且解決網站全部的問題呢？

　　這個問題的回答固然是不可能的。一個網站是永遠無法擺脫與異步請求相對的同步請求，就算有個網站把異步作到了極致，可是它也沒法擺脫用戶第一次訪問要在瀏覽器地址欄填寫網站入口頁面url地址的同步請求問題，網站把異步操做作到極致也無非就是把網站作成了一個純粹的單頁面形式而已。

　　純粹單頁面的網站不少人一聽到就以爲好牛逼啊，很前衛，很厲害，對前端有所瞭解的人還會想到單頁面也就意味要運用更多的javascript編程和DOM編程，前端代碼難度也會大大加強，好的單頁面應用若是這個應用還包含複雜的業務邏輯，那麼單頁面前端開發裏極可能還會使用到現在很火爆的javascript模塊技術例如requirejs或者seajs技術，單頁面聽起來實在太完美了，可是咱們冷靜下來思考下，單頁面真的完美嗎？下面我要爲單頁面潑潑涼水了，具體以下：

　　潑涼水一：單頁面其實指的是網站只有一個入口，可是並不表明用戶看到的網頁就是一個樣子的，單頁面裏也會有不少頁面切換，可是無論頁面裏的模樣如何變化，瀏覽器地址欄的地址都不會變化，能作到這點就得歸功ajax的超強能力了，單頁面不一樣模樣的展現都是在javascript代碼裏實現的，那麼問題來了，單頁面對於搜索引擎的網絡爬蟲就很是不友好了，由於網絡爬蟲是根據url抓取頁面，抓取完畢後會忽略javascript代碼，那麼單頁面的設計方案就會致使SEO優化只能做用於首頁，而網站其餘頁面將無非有效的被SEO技術進行優化。

　　潑涼水二：一個網站作成單頁面之後那麼網站不一樣的展現都在一個url下面，可是若是有些用戶只是對網站的某一部分功能很感興趣，而這部分功能又不是被單頁面的惟一同步請求所展現的首頁裏的內容，那麼結果就是這些用戶每次登錄網站時候都要手動操做一下才能進入本身想要的功能頁面裏，假如首頁進入功能頁面的操做步驟比較繁瑣，那麼這個必然會致使網站用戶體驗的降低。

　　那麼上面的問題該如何來破呢？

　　這裏我首先來說講第二個問題的解決方案，第二個潑涼水的問題的核心就是要記錄單頁面的狀態問題，這個狀態能夠幫助首頁能快速切換到具體的功能頁面，要讓客戶端網頁有狀態最經常使用的手段就是cookie了，若是瀏覽器支持html5，那麼保存狀態的手段就更多，能力也更強了。可是這種手段是和客戶端緊耦合的，那麼若是碰到這種狀況，該手段就會出現問題了，例如若是有我的發現單頁面網站裏一個頗有趣的功能，這時候他正好和朋友QQ聊天，他告訴了他的朋友，他的朋友也該興趣，讓他把連接發過來，那麼這個朋友就不得不在從首頁在重複操做一遍，因而可知，cookie的手段並無全面解決這個問題，那咱們還有其餘手段嘛？

　　答案是還真有，那就是使用html的錨連接，錨連接的形式以下所示：

http://www.baidu.com/#sharpxiajun

 

　　下面是我摘抄下百度百科對錨連接的解釋：

錨連接實際上就是連接文本，又叫錨文本。能夠理解爲：帶有文本的超連接，就叫錨連接。錨文本能夠做爲文本連接所在的頁面的內容的評估。

通常的來說，網站頁面中增長的錨連接都和頁面自己的內容有必定的必然聯繫。網站建設的行業網站上會增長一些同行網站的連接或者一些作網站建設的知名設計網站的連接；

另外一方面，錨文本能做爲對所指向頁面的評估。錨文本能精確的描述所指向頁面的內容，我的網站上增長Google的連接，錨文本爲 「搜索引擎」。這樣經過錨文本自己就能知道，Google是搜索引擎。

 

　　那麼在單頁面裏的功能切換時候咱們改變一下url上的錨文字，反過來講使用錨文字作路由器，讓其能夠路由到對應的功能頁面那麼上面的問題不就能夠解決了。關於錨連接我這裏要補充一些知識，首先錨連接的形式是url#文字，錨的起始標記是#號，這個#號的內容實際上是屬於瀏覽器端的，也就是說#包括#號後面的內容是不會被髮送到服務端的，那麼咱們想改變錨連接只能在客戶端進行，可是傳統的錨連接的變化是很難被javascript語言監控到的，直到html5的出現才從根本上解決了這個問題，html5提供了hashchange事件，該事件能夠監控錨連接的變化，由於javascript語言能夠監控錨連接的變化，那麼使用錨連接路由功能頁面就成爲了可能，那麼低版本的瀏覽器該怎麼辦了？這個主要是ie的問題了，其實ie8包括ie8都支持hashchange事件，再低就不行了，不過jQuery有個插件可讓低版本的ie支持hashchange事件，有興趣的童鞋能夠百度下啊。

　　看來潑涼水二問題是有解的，那麼潑涼水一怎麼解決了？個人回答是基本無解，這個問題的關鍵在網絡爬蟲這邊，若是咱們被動解決這個問題，那隻能是拋棄javascript了，這個玩笑就開大了，因此咱們只好祈求各大搜索引擎能不能智能化再厲害點了。這裏加個題外話，我最近幾天忽然意識到一個問題，那就是講到web前端技術我必定要增強對SEO的思考，由於絕大多數網站都會把搜素引擎當作入口的生命線，這是一個很難迴避的問題，無論咱們網站作的如何優秀，假如用戶很難找到它，那一切都將會是百搭，而在前端設計裏要加入SEO的思考，這必然會致使整個架構的重大變化。這個問題我會在以網站靜態化角度審視先後端分離方案時候重點講下。

　　前端MVC討論到這裏咱們會發現咱們的談論裏缺了一環那就是MVC的M層模型層，web前端要侵入到模型層了，這不就等於web前端要造反了，它不只僅想改變從屬服務端的悲慘命運，還要搶奪服務端的部分功能，讓服務端成爲瀏覽器對應的存儲系統，這不是無異於虎口奪食，在時下服務端如此強勢的大環境下，這種想法簡直就是活得不耐煩了，哈哈，固然這是戲言了，作技術作工程仍是要講求個合理性和邏輯性的，技術和工程都是實在的東西很講道理的，只要道理站得住腳怎麼個作法都是其次，回到問題自己，我我的以爲在PC端討論web前端作模型層其實每每利大於弊，就安全而言，模型層意味有大量業務邏輯推移到web前端，那麼安全的保障難度會加大，就技術難度而言，web前端作模型層會讓javascript編程巨複雜，因此要作這個抉擇時候必定要結合業務作仔細的權衡，其實我如今接觸的一些說包含模型層能力的前端框架在實際運用裏模型層的功能仍是使用太少，不過這個問題若是放到移動端，或者是PC和移動端融合可能就會有些不一樣，這個問題我將在本系列的終篇裏再談談，這裏也不累述了。

　　說到這裏須要總結下了，前端的MVC不該該等於單頁面開發，前端MVC也不是把ajajx用到極致，根據實際業務場景，咱們須要適當的把同步請求和異步請求結合起來。若是前端MVC裏包含了更多同步請求，那麼對於MVC裏的C層即控制層就會有更高的要求。先後端分離主題還有個下篇，下篇裏我還會提到一種先後端分離方案那就是nodejs的運用，而nodejs的運用就是和控制層有密切的關係，上篇裏我提到nodejs是先後端分離方案的催化劑，其實我我的認爲nodejs參入的先後端分離方案纔是更加完美些的先後端分離方案，這個完美的評價緣由之一就是從前端承擔控制層做用角度思考的，因此前端控制層這個內容我將放在下篇討論。

　　好了，本篇寫完了，從本篇咱們能夠看到前端MVC的歷史很早，它的出現早於nodejs,這就說明前端MVC其實並非什麼新技術，只不過是如今才被你們重視起來，完善它的人也愈來愈多。從本篇咱們還發現前端MVC其實並不完美，問題不少，最致命的就是對網絡爬蟲的不友好，因此咱們須要考慮到SEO技術參入其中的先後端分離方案。

    原文：http://www.cnblogs.com/sharpxiajun/p/4314387.html