[[155800]]

項(xiàng)目背景

剛剛參加完一個(gè)項(xiàng)目，背景：后端是用java，后端服務(wù)已經(jīng)開發(fā)的差不多了，現(xiàn)在要通過web的方式對外提供服務(wù)，也就是B/S架構(gòu)。后端專注做業(yè)務(wù)邏輯，不想在后端做頁面渲染的事情，只向前端提供數(shù)據(jù)接口。于是協(xié)商后打算將前后端完全分離，頁面上的所有數(shù)據(jù)都通過ajax向后端取，頁面渲染的事情完全由前端來做。另外還有一個(gè)緊急的情況，項(xiàng)目要緊急上線，整個(gè)web站點(diǎn)的開發(fā)時(shí)間只有兩周，兩周??！于是在這樣的背景下，決定開始一次前后端完全分離的嘗試。

之前開發(fā)都是同步渲染和異步渲染混搭的，有些東西可以有后端PHP幫你編譯好，如通用的頁面模板，后端傳回的頁面參數(shù)等。提前預(yù)感到這次完全分離可能會(huì)遇到一些困難，但是項(xiàng)目上線要緊，也不能深入搞架構(gòu)，于是打算就用jQuery+handlebars，jQuery來完成頁面邏輯和DOM操作，用handlebars來完成頁面渲染，這個(gè)方案是如此的簡單粗暴，但好處能最穩(wěn)妥的保證項(xiàng)目按期完成。其實(shí)前后端分離并不是一件容易的工作，這么做會(huì)有諸多不完善之處，后面再談。

淺談前后端分離

所謂的前后端分離，到底是分離什么呢？其實(shí)就是頁面的渲染工作，之前是后端渲染好頁面，交給前端來顯示，分離后前端需要自己拼裝html代碼，然后再顯示。前端來管理頁面的渲染有很多好處，比如減少網(wǎng)絡(luò)請求量，制作單頁面應(yīng)用等。事情聽起來簡單，但這么一分離又會(huì)牽扯到很多問題，比如：

•  資源的按需加載。尤其是在單頁應(yīng)用中。
• 頁面展現(xiàn)邏輯。分離讓前端的邏輯陡增，需要有一個(gè)良好的前端架構(gòu)，如mvc模式。
• 數(shù)據(jù)校驗(yàn)。因?yàn)轫撁鏀?shù)據(jù)都是從后端請求來的，必須校驗(yàn)要展示的數(shù)據(jù)是否合法，避免xss或其他安全問題。
• 短暫白屏。因?yàn)轫撁娌皇峭戒秩镜模谡埱髷?shù)據(jù)完畢之前，頁面是白屏的，體驗(yàn)很不好。
• 代碼的復(fù)用。眾多的模板、邏輯模塊需要良好組織實(shí)現(xiàn)可復(fù)用。
• 路由控制。無刷新的前端體驗(yàn)同時(shí)毀掉了瀏覽器的后退按鈕，前端視圖需要有一套路由機(jī)制。
• SEO。服務(wù)端不再返回頁面，前端根據(jù)不同的邏輯呈現(xiàn)不同的視圖（并非頁面），要對搜索引擎友好需要做很多額外的工作。

以上每一個(gè)問題都?jí)蚣郑幚砗眯枰性O(shè)計(jì)精良又符合實(shí)際項(xiàng)目的方案?，F(xiàn)在已經(jīng)有很多框架可以幫我們做這些事情，Backbone, EmberJS, KnockoutJS, AngularJS, React, avalon等等，利用它們可以架構(gòu)起一個(gè)富前端。但框架畢竟是框架，要利用到實(shí)際項(xiàng)目中，還是需要有自己的設(shè)計(jì)，框架并不能解決所有的問題。

之前也有看過淘寶團(tuán)隊(duì)的實(shí)踐，利用nodejs做一個(gè)中間層，處理頁面渲染、路由控制、SEO等事情，將前后端的分界線進(jìn)行了重新定義。個(gè)人感覺這應(yīng)該是一個(gè)正確的方向，有點(diǎn)顛覆的感覺，前端走向工程化，將變成真正的全棧式大前端。不知現(xiàn)在這種架構(gòu)是否在淘寶全面鋪開，真有點(diǎn)期待看看效果。

以上的框架，還有淘寶的實(shí)踐，畢竟都是大牛之作，我這個(gè)小輩也只是參考學(xué)習(xí)過，未能在實(shí)際項(xiàng)目中使用。低頭看看自己現(xiàn)在手頭的項(xiàng)目，1個(gè)前端，2周時(shí)間，要完成一個(gè)完整的web項(xiàng)目，還是用最穩(wěn)妥***級(jí)的方式來搞吧~

基本結(jié)構(gòu)

項(xiàng)目整體并不是一個(gè)單頁應(yīng)用，但有些模塊需要做成局部的單頁操作，像這種需要分步完成的操作，只需局部加載子頁面即可。

[[155801]]

因此，一個(gè)模塊有一個(gè)主html頁面，初始只有一些基本的骨架，有一個(gè)名字相同的js文件，該模塊邏輯都在此js文件中，有一個(gè)名字相同的css文件，該模塊的所有樣式都定義在此css文件中。

需要異步加載的子頁面，像上圖中每個(gè)步驟的頁面，我都使用jQuery的$.load()方法來加載，此方法能在頁面某個(gè)容器中加載內(nèi)容，并可指定回調(diào)函數(shù)，使用起來很方便。被異步加載的子頁面我都用_開頭，如_step1.html，用于做區(qū)分。

為了確保瀏覽器的前進(jìn)后退按鈕可用，我使用了hash來做路由標(biāo)記，頁面地址如：publish.html#step2。有個(gè)缺陷是hash并不會(huì)發(fā)送給服務(wù)器，所以SEO就廢了。事實(shí)上使用history API也可以更優(yōu)雅的解決問題，但需要考慮兼容性，還有額外工作要做，考慮時(shí)間因素，退而求其次，況且本項(xiàng)目也無需做SEO?；蛘呦裉詫毜姆桨改菢?，nodejs層與瀏覽器層統(tǒng)一路由，SEO問題可以迎刃而解。但又明顯不在本人的實(shí)力范圍之內(nèi)，汗--！

除了用$.load異步加載的子頁面，剩余的局部頁面就是用handlebars提供的模板渲染了，我使用了handlebars的預(yù)編譯功能，不得不說很強(qiáng)大，一來節(jié)約了頁面加載階段所需的編譯時(shí)間（編譯handlebars模板），二來編譯后的模板（js文件）方便復(fù)用。

接下來就是前端邏輯如何組織，因?yàn)闆]有用mv*框架，所以只能靠自己來寫一個(gè)便于開發(fā)的結(jié)構(gòu)。如上面所述，每個(gè)模塊有一個(gè)主js文件，文件內(nèi)容結(jié)構(gòu)如下：

var publish = { 
     //該模塊初始化入口 
     init : function(){ 
          this.renderData(param); 
          this.initListeners(); 
     }, 
     //內(nèi)部所用的函數(shù) 
     renderData : function(param){ 
          //渲染數(shù)據(jù)。。 
     }, 
     //統(tǒng)一綁定監(jiān)聽器 
     initListeners : function(){ 
          $(document.body).delegates({ 
               '.btn' : function(){ 
                    //點(diǎn)擊事件 
               }, 
               '.btn2' : function(){ 
                    //點(diǎn)擊事件2 
               }, 
               '.checkbox' : { 
                    'change' : function(){ 
                         //change事件 
                    } 
               } 
          }); 
     } 
} 

每個(gè)模塊給一個(gè)命名空間，所有的方法都掛在上面，js文件中只做函數(shù)的定義，不立即執(zhí)行任何東西，然后在html文件中調(diào)用入口方法:publish.init()。業(yè)務(wù)邏輯都封裝到函數(shù)中，如上面的renderData，然后供其他地方調(diào)用。頁面的事件監(jiān)聽器統(tǒng)一都注冊在body元素上，用事件代理來完成，為了避免寫太多的on、click之類代碼，為jQuery擴(kuò)展了一個(gè)delegates方法，用來以配置的方式統(tǒng)一綁定監(jiān)聽器，用法如上所示。把delegates定義的代碼也放出來吧：

//以配置的方式代理事件 
$.fn.delegates = function(configs) { 
     el = $(this[0]); 
     for (var name in configs) { 
          var value = configs[name]; 
          if (typeof value == 'function') { 
               var obj = {}; 
               obj.click = value; 
               value = obj; 
          }; 
          for (var type in value) { 
               el.delegate(name, type, value[type]); 
          } 
     } 
     return this; 
} 

基本的結(jié)構(gòu)就是這樣，沒有什么新技術(shù)，只是把現(xiàn)有的東西做了一下組合。但工作到此還遠(yuǎn)遠(yuǎn)沒有結(jié)束，在實(shí)際應(yīng)用中還會(huì)有一些東西需要處理，下面來詳細(xì)說說：

公共頭部底部的引用

這是一個(gè)比較棘手的問題，一般通用的頭部和底部會(huì)放一些公共的代碼，如頁面外層結(jié)構(gòu)html代碼，站點(diǎn)使用的庫如jQuery、handlebars，站點(diǎn)通用js和css文件。在傳統(tǒng)的開發(fā)中，通常是寫一個(gè)單獨(dú)的文件如head.html，在其他頁面中用后端代碼如include語句引入，由此來進(jìn)行復(fù)用。

現(xiàn)在前后端分離后，無法依靠后端來給你渲染，所以得在前端做了。既然用了handlebars，很容易想到把公用部分寫成一個(gè)模板，然后預(yù)編譯出來，生成一個(gè)header.js文件，然后在其他頁面引用。然而在實(shí)際操作中發(fā)現(xiàn)了一個(gè)問題，handlebars是靜態(tài)模板，編譯后生成的字符串通過innerHTML的方式插入到頁面，在一般的模板中這樣是沒問題的?，F(xiàn)在有個(gè)問題是header中有一些<script>標(biāo)簽，外鏈著要使用的庫，通過innerHTML插入<scirpt>標(biāo)簽，瀏覽器并不會(huì)發(fā)送請求加載對應(yīng)的js文件，所以就出問題了。

搜索、嘗試了多種方之后，最終的方案定為：用document.write()將編譯結(jié)果寫到頁面，這樣<script>標(biāo)簽?zāi)軌蛘＜虞d。所以每個(gè)頁面使用頭部的代碼就變成這樣：

<script src="static/js/tpl/head.js"></script> 
     <p id="header"> 
          <script src="static/js/includeHead.js"></script> 
     </p> 

includeHead.js中的代碼如下：

function includeHead(){ 
     var header = document.getElementById('header'); 
     var compileHead = Handlebars.templates['head']; 
     var head = compileHead({}); 
     document.write(head); 
} 
includeHead(); 

看著是有點(diǎn)別扭，不過為了實(shí)現(xiàn)功能，目前也就只能這樣了。

雖然用原生的innerHTML無法加載<script>標(biāo)簽中的內(nèi)容，但是jQuery的$().html()方法進(jìn)行了優(yōu)化，可以查找到<script>標(biāo)簽并且執(zhí)行里面的代碼，所以用$().html()是可以完成上面的工作的。

這么一看，這個(gè)蹩腳的方案就可以替換了?！　?/p>

路由控制

如上面所述，jQuery的$.load()方法可以滿足加載子頁面的需求，現(xiàn)在需要解決的問題是，不管用戶刷新頁面還是前進(jìn)后退，我們都得根據(jù)hash值來渲染對應(yīng)的視圖，其實(shí)就是路由控制。這個(gè)時(shí)候就需要監(jiān)聽hashchange事件了，我定義了一個(gè)loadPage方法用來加載子頁面，然后綁定監(jiān)聽器如下：

window.onhashchange = this.loadPage; 

在loadPage方法中，根據(jù)hash的值來調(diào)用$.load()方法，子頁面的初始化工作，在$.load()的回調(diào)函數(shù)中指定。

這樣做還有一個(gè)便捷之處，我們切換視圖不必手動(dòng)調(diào)loadPage方法，只需要修改頁面的hash就可以了，hash發(fā)生變化被監(jiān)聽到，自動(dòng)加載對應(yīng)的子頁面。例如，點(diǎn)擊下一步進(jìn)入步驟二：

'.next' : function(){ 
        location.href = '#step2'; 
} 

如此便實(shí)現(xiàn)了一個(gè)簡單的路由控制，由于不是整站單頁面，也沒有多級(jí)路由，這樣完全可以滿足需求。至于SEO，就只能呵呵了，正好項(xiàng)目也不需要做SEO，否則此方法得作罷。

另外想說的一點(diǎn)就是頁面的緩存，異步加載來的內(nèi)容可以存在localStorage中，也可以放在頁面上進(jìn)行顯隱控制，這樣用戶在頻繁切換視圖的時(shí)候無需再次請求，回到上一步的時(shí)候之前填好的表單數(shù)據(jù)也不會(huì)消失，體驗(yàn)會(huì)非常好。

頁面間參數(shù)傳遞

有時(shí)候我們需要給訪問的頁面?zhèn)鲄?shù)，比如訪問一個(gè)設(shè)備的詳細(xì)信息頁，要把設(shè)備id給傳過去，detail.html?id=1，這樣detail頁面可以根據(jù)id去請求對應(yīng)的數(shù)據(jù)。傳統(tǒng)由后端渲染的頁面，url中的參數(shù)會(huì)發(fā)送到服務(wù)端，服務(wù)端接收后可以再渲染到頁面上供js使用。我們現(xiàn)在不行了，請求頁面壓根不跟后端打交道，但這個(gè)參數(shù)是必不可少的，所以需要前端有一套傳遞參數(shù)的機(jī)制。

其實(shí)非常簡單，通過location.href可以拿到當(dāng)前的url地址，然后進(jìn)行字符串匹配，把參數(shù)提取出來就可以了?？瓷先ネν流M的，但工作起來良好，另外也有考慮過用cookie來傳遞，感覺有點(diǎn)麻煩。

由于這些參數(shù)通常是寫在<a>標(biāo)簽上的，而<a>標(biāo)簽又是根據(jù)動(dòng)態(tài)數(shù)據(jù)渲染出來的（因?yàn)槭莿?dòng)態(tài)參數(shù)），我們不可能在頁面渲染完后，用js修改所有<a>標(biāo)簽的href值，給它追加一個(gè)參數(shù)。怎么辦呢？這時(shí)候handlebars就派上用場了，我們可以使用handlebars***的helper，在渲染頁面的時(shí)候直接查詢url中的參數(shù)，然后輸出在編譯好的代碼中。我在handlebars中注冊了一個(gè)helper，如下：

Handlebars.registerHelper('param', function(key, options){ 
    var url = location.href.replace(/^[^?=]*\?/ig, '').split('#')[0]; 
    var json = {}; 
    url.replace(/(^|&)([^&=]+)=([^&]*)/g, function (a, b, key , value){ 
        try { 
            key = decodeURIComponent(key); 
        } catch(e) {} 
 
        try { 
            value = decodeURIComponent(value); 
        } catch(e) {} 
 
        if (!(key in json)) { 
            json[key] = /\[\]$/.test(key) ? [value] : value; 
        } 
        else if (json[key] instanceof Array) { 
            json[key].push(value); 
        } 
        else { 
            json[key] = [json[key], value]; 
        } 
    }); 
    return key ? json[key] : json; 
}); 

這個(gè)名為param的helper可以輸出你所要查詢的參數(shù)值，然后可以直接寫在模板中，如：

<a href="detail.html?id={{param id}}">設(shè)備詳細(xì)信息</a> 

這樣就方便多了！但是這么做有沒有問題呢？其實(shí)是有些不***的，如果你考慮“性能”二字的話。一個(gè)url中參數(shù)的值是固定的，而你每次使用這個(gè)helper都會(huì)計(jì)算一遍，白白做了多余的事情。如果handlebars可以在模板中定義常量就好了，可惜我找遍文檔沒發(fā)現(xiàn)有這個(gè)功能。只能為了方便犧牲性能了，也正印證了我標(biāo)題中所說的“簡單粗暴”，呵呵。

數(shù)據(jù)的校驗(yàn)和處理

由于數(shù)據(jù)是由后端傳來的，有很多不確定性，數(shù)據(jù)可能不合法，或者結(jié)構(gòu)有錯(cuò)，或者直接是空的。因此前端有必要對數(shù)據(jù)做一個(gè)合法性的校驗(yàn)。借助handlebars，可以很方便的進(jìn)行數(shù)據(jù)校驗(yàn)。沒錯(cuò)，就是利用helper。handlebars內(nèi)置的helper如if、each都支持else語句，出錯(cuò)信息可以在else中輸出。如果需要個(gè)性化的校驗(yàn)，我們可以自己定義helper來完成，關(guān)于如何自定義helper，我之前研究了下，寫過一篇文章：http://www.cnblogs.com/lvdabao/p/handlebars_helper.html?？傊远xhelper很強(qiáng)大，可以完成你所需的任何邏輯。

數(shù)據(jù)的格式化，如日期、數(shù)字等，也可以通過helper來完成。

另外一方面，前端還應(yīng)對數(shù)據(jù)進(jìn)行html轉(zhuǎn)義，避免xss，由于handlebars已經(jīng)給做了html轉(zhuǎn)義，所以我們可以直接忽略此項(xiàng)了。

總結(jié)

本文是我剛剛參加完一個(gè)項(xiàng)目后所寫，記錄一下整個(gè)過程遇到的問題及處理方式，其他的一些細(xì)碎點(diǎn)如表單異步提交什么的，不是本文重點(diǎn)，不寫了。這是我***次實(shí)踐前后端完全分離的項(xiàng)目，整個(gè)前端全由我來設(shè)計(jì)、開發(fā)。2周時(shí)間，憑著這套方案，項(xiàng)目按期開發(fā)完成，而且還提前完成了，預(yù)留出一天多的時(shí)間測試了一遍。

雖然開發(fā)任務(wù)是完成了，但是回頭看一下整個(gè)方案，并不是很優(yōu)雅也沒有什么技術(shù)含量，文章開頭提到的幾個(gè)問題都沒有解決。所以***為簡單粗暴的方案，都是為了趕工期啊。

***，如果給我再來一次的機(jī)會(huì)，并且時(shí)間充足，我一定要嘗試用mv*方案來搞一下，或angular，或avalon。