隨著不同終端(Pad/Mobile/PC)的興起，對開發(fā)人員的要求越來越高，純?yōu)g覽器端的響應(yīng)式已經(jīng)不能滿足用戶體驗(yàn)的高要求，我們往往需要針對不同的終端開發(fā)定制的版本。為了提升開發(fā)效率，前后端分離的需求越來越被重視，后端負(fù)責(zé)業(yè)務(wù)/數(shù)據(jù)接口，前端負(fù)責(zé)展現(xiàn)/交互邏輯，同一份數(shù)據(jù)接口，我們可以定制開發(fā)多個版本。
一、什么是前后端分離？
最開始組內(nèi)討論的過程中我發(fā)現(xiàn)，每個人對前后端分離的理解不一樣，為了保證能在同一個頻道討論，先就什么是”前后端分離”達(dá)成一致。
大家一致認(rèn)同的前后端分離的例子就是SPA(Single-page application)，所有用到的展現(xiàn)數(shù)據(jù)都是后端通過異步接口(AJAX/JSONP)的方式提供的，前端只管展現(xiàn)。
從某種意義上來說，SPA確實(shí)做到了前后端分離，但這種方式存在兩個問題：
WEB服務(wù)中，SPA類占的比例很少。很多場景下還有同步/同步+異步混合的模式，SPA不能作為一種通用的解決方案。
現(xiàn)階段的SPA開發(fā)模式，接口通常是按照展現(xiàn)邏輯來提供的，有時候?yàn)榱颂岣咝剩蠖藭臀覀兲幚硪恍┱宫F(xiàn)邏輯，這就意味著后端還是涉足了View層的工作，不是真正的前后端分離。
前端：負(fù)責(zé)View和Controller層。
后端：只負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)等。
SPA式的前后端分離，是從物理層做區(qū)分（認(rèn)為只要是客戶端的就是前端，服務(wù)器端的就是后端），這種分法已經(jīng)無法滿足我們前后端分離的需求，我們認(rèn)為從職責(zé)上劃分才能滿足目前我們的使用場景：
為什么去做這種職責(zé)的劃分，后面會繼續(xù)探討。
二、為什么要前后端分離？
關(guān)于這個問題，玉伯的文章Web研發(fā)模式演變中解釋得非常全面，我們再大概理一下：
2.1 現(xiàn)有開發(fā)模式的適用場景
玉伯提到的幾種開發(fā)模式，各有各的適用場景，沒有哪一種完全取代另外一種。
比如后端為主的MVC，做一些同步展現(xiàn)的業(yè)務(wù)效率很高，但是遇到同步異步結(jié)合的頁面，與后端開發(fā)溝通起來就會比較麻煩。
Ajax為主SPA型開發(fā)模式，比較適合開發(fā)APP類型的場景，但是只適合做APP，因?yàn)镾EO等問題不好解決，對于很多類型的系統(tǒng)，這種開發(fā)方式也過重。
2.2 前后端職責(zé)不清
在業(yè)務(wù)邏輯復(fù)雜的系統(tǒng)里，我們最怕維護(hù)前后端混雜在一起的代碼，因?yàn)闆]有約束，M-V-C每一層都可能出現(xiàn)別的層的代碼，日積月累，完全沒有維護(hù)性可言。
雖然前后端分離沒辦法完全解決這種問題，但是可以大大緩解。因?yàn)閺奈锢韺哟紊媳ＷC了你不可能這么做。
2.3 開發(fā)效率問題
淘寶的Web基本上都是基于MVC框架webx，架構(gòu)決定了前端只能依賴后端。
所以我們的開發(fā)模式依然是，前端寫好靜態(tài)demo，后端翻譯成VM模版，這種模式的問題就不說了，被吐槽了很久。
直接基于后端環(huán)境開發(fā)也很痛苦，配置安裝使用都很麻煩。為了解決這個問題，我們發(fā)明了各種工具，比如VMarket，但是前端還是要寫VM，而且依賴后端數(shù)據(jù)，效率依然不高。
另外，后端也沒法擺脫對展現(xiàn)的強(qiáng)關(guān)注，從而專心于業(yè)務(wù)邏輯層的開發(fā)。
2.4 對前端發(fā)揮的局限
性能優(yōu)化如果只在前端做空間非常有限，于是我們經(jīng)常需要后端合作才能碰撞出火花，但由于后端框架限制，我們很難使用Comet、Bigpipe等技術(shù)方案來優(yōu)化性能。
為了解決以上提到的一些問題，我們進(jìn)行了很多嘗試，開發(fā)了各種工具，但始終沒有太多起色，主要是因?yàn)槲覀冎荒茉诤蠖私o我們劃分的那一小塊空間去發(fā)揮。只有真正做到前后端分離，我們才能徹底解決以上問題。
三、怎么做前后端分離？
怎么做前后端分離，其實(shí)第一節(jié)中已經(jīng)有了答案：
前端：負(fù)責(zé)View和Controller層。
后端：負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)等。
試想一下，如果前端掌握了Controller，我們可以做url design，我們可以根據(jù)場景決定在服務(wù)端同步渲染，還是根據(jù)view層數(shù)據(jù)輸出json數(shù)據(jù)，我們還可以根據(jù)表現(xiàn)層需求很容易的做Bigpipe,Comet,Socket等等，完全是需求決定使用方式。
暫無評論，快來評論吧!