歡迎光臨
每天分享高質量文章

一個簡單粗暴的前後端分離方案

專案背景

剛剛參加完一個專案,背景:後端是用java,後端服務已經開發的差不多了,現在要通過web的方式對外提供服務,也就是B/S架構。後端專註做業務邏輯,不想在後端做頁面渲染的事情,只向前端提供資料接口。於是協商後打算將前後端完全分離,頁面上的所有資料都通過ajax向後端取,頁面渲染的事情完全由前端來做。另外還有一個緊急的情況,專案要緊急上線,整個web站點的開發時間只有兩周,兩周啊!於是在這樣的背景下,決定開始一次前後端完全分離的嘗試。

之前開發都是同步渲染和異步渲染混搭的,有些東西可以有後端PHP幫你編譯好,如通用的頁面模板,後端傳回的頁面引數等。提前預感到這次完全分離可能會遇到一些困難,但是專案上線要緊,也不能深入搞架構,於是打算就用jQuery+handlebars,jQuery來完成頁面邏輯和DOM操作,用handlebars來完成頁面渲染,這個方案是如此的簡單粗暴,但好處能最穩妥的保證專案按期完成。其實前後端分離並不是一件容易的工作,這麼做會有諸多不完善之處,後面再談。

淺談前後端分離

所謂的前後端分離,到底是分離什麼呢?其實就是頁面的渲染工作,之前是後端渲染好頁面,交給前端來顯示,分離後前端需要自己拼裝html代碼,然後再顯示。前端來管理頁面的渲染有很多好處,比如減少網絡請求量,製作單頁面應用等。事情聽起來簡單,但這麼一分離又會牽扯到很多問題,比如:

  • 資源的按需加載。尤其是在單頁應用中。

  • 頁面展現邏輯。分離讓前端的邏輯陡增,需要有一個良好的前端架構,如mvc樣式。

  • 資料校驗。因為頁面資料都是從後端請求來的,必須校驗要展示的資料是否合法,避免xss或其他安全問題。

  • 短暫白屏。因為頁面不是同步渲染的,在請求資料完畢之前,頁面是白屏的,體驗很不好。

  • 代碼的復用。眾多的模板、邏輯模塊需要良好組織實現可復用。

  • 路由控制。無掃清的前端體驗同時毀掉了瀏覽器的後退按鈕,前端視圖需要有一套路由機制。

  • SEO。服務端不再傳回頁面,前端根據不同的邏輯呈現不同的視圖(並非頁面),要對搜索引擎友好需要做很多額外的工作。

以上每一個問題都夠棘手,要處理好需要有設計精良又符合實際專案的方案。現在已經有很多框架可以幫我們做這些事情,Backbone, EmberJS, KnockoutJS, AngularJS, React, avalon等等,利用它們可以架構起一個富前端。但框架畢竟是框架,要利用到實際專案中,還是需要有自己的設計,框架並不能解決所有的問題。

之前也有看過淘寶團隊的實踐,利用nodejs做一個中間層,處理頁面渲染、路由控制、SEO等事情,將前後端的分界線進行了重新定義。個人感覺這應該是一個正確的方向,有點顛覆的感覺,前端走向工程化,將變成真正的全棧式大前端。不知現在這種架構是否在淘寶全面鋪開,真有點期待看看效果。

以上的框架,還有淘寶的實踐,畢竟都是大牛之作,我這個小輩也只是參考學習過,未能在實際專案中使用。低頭看看自己現在手頭的專案,1個前端,2周時間,要完成一個完整的web專案,還是用最穩妥最低級的方式來搞吧~

基本結構

專案整體並不是一個單頁應用,但有些模塊需要做成區域性的單頁操作,像這種需要分步完成的操作,只需區域性加載子頁面即可。

因此,一個模塊有一個主html頁面,初始只有一些基本的骨架,有一個名字相同的js檔案,該模塊邏輯都在此js檔案中,有一個名字相同的css檔案,該模塊的所有樣式都定義在此css檔案中。

需要異步加載的子頁面,像上圖中每個步驟的頁面,我都使用jQuery的$.load()方法來加載,此方法能在頁面某個容器中加載內容,並可指定回呼函式,使用起來很方便。被異步加載的子頁面我都用_開頭,如_step1.html,用於做區分。

為了確保瀏覽器的前進後退按鈕可用,我使用了hash來做路由標記,頁面地址如:publish.html#step2。有個缺陷是hash並不會發送給服務器,所以SEO就廢了。事實上使用history API也可以更優雅的解決問題,但需要考慮兼容性,還有額外工作要做,考慮時間因素,退而求其次,況且本專案也無需做SEO。或者像淘寶的方案那樣,nodejs層與瀏覽器層統一路由,SEO問題可以迎刃而解。但又明顯不在本人的實力範圍之內,汗–!

除了用$.load異步加載的子頁面,剩餘的區域性頁面就是用handlebars提供的模板渲染了,我使用了handlebars的預編譯功能,不得不說很強大,一來節約了頁面加載階段所需的編譯時間(編譯handlebars模板),二來編譯後的模板(js檔案)方便復用。

接下來就是前端邏輯如何組織,因為沒有用mv*框架,所以只能靠自己來寫一個便於開發的結構。如上面所述,每個模塊有一個主js檔案,檔案內容結構如下:

var publish = {

//該模塊初始化入口

init : function(){

this.renderData(param);

this.initListeners();

},

//內部所用的函式

renderData : function(param){

//渲染資料。。

},

//統一系結監聽器

initListeners : function(){

$(document.body).delegates({

‘.btn’ : function(){

//點擊事件

},

‘.btn2’ : function(){

//點擊事件2

},

‘.checkbox’ : {

‘change’ : function(){

//change事件

}

}

});

}

}

每個模塊給一個命名空間,所有的方法都掛在上面,js檔案中只做函式的定義,不立即執行任何東西,然後在html檔案中呼叫入口方法:publish.init()。業務邏輯都封裝到函式中,如上面的renderData,然後供其他地方呼叫。頁面的事件監聽器統一都註冊在body元素上,用事件代理來完成,為了避免寫太多的on、click之類代碼,為jQuery擴展了一個delegates方法,用來以配置的方式統一系結監聽器,用法如上所示。把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;

}

基本的結構就是這樣,沒有什麼新技術,只是把現有的東西做了一下組合。但工作到此還遠遠沒有結束,在實際應用中還會有一些東西需要處理,下麵來詳細說說:

公共頭部底部的取用

這是一個比較棘手的問題,一般通用的頭部和底部會放一些公共的代碼,如頁面外層結構html代碼,站點使用的庫如jQuery、handlebars,站點通用js和css檔案。在傳統的開發中,通常是寫一個單獨的檔案如head.html,在其他頁面中用後端代碼如include陳述句引入,由此來進行復用。

現在前後端分離後,無法依靠後端來給你渲染,所以得在前端做了。既然用了handlebars,很容易想到把公用部分寫成一個模板,然後預編譯出來,生成一個essay-header.js檔案,然後在其他頁面取用。然而在實際操作中發現了一個問題,handlebars是靜態模板,編譯後生成的字串通過innerHTML的方式插入到頁面,在一般的模板中這樣是沒問題的。現在有個問題是essay-header中有一些

分享創造快樂