當我在開始架構(gòu)一個JS 應(yīng)用的原型時，我總是嘗試把這些組件設(shè)計成既能被Backbone.js應(yīng)用使用也能被一次性的腳本或者工程使用的結(jié)構(gòu)。這些結(jié)構(gòu)性的組件增長十分迅速，他們變得十分龐雜。在這篇文章中，我將會研究后端API服務(wù)層的動機，優(yōu)點，缺點以及建議或者頭腦風(fēng)暴他們的代替實現(xiàn)方式。

后端API服務(wù)層

盡管你可能實現(xiàn)了你的后端API（MVC或者別的方式），但是記憶和重復(fù)實現(xiàn)API的細節(jié)是非常笨重的。當一個團隊成員說他們開發(fā)一些東西需要登錄功能，他們是需要重復(fù)造輪子還是你給他們一個預(yù)編譯的JS函數(shù)調(diào)用呢？

我希望建立一個名字為younow.js的JS客戶端來解決這些問題，這將允許任何JS應(yīng)用和我們的后臺交互。有一個新增的需求需要登錄功能？不用擔(dān)心！ 只要調(diào)用YouNow.Api.login()并且綁定處理函數(shù)就行。在這個例子中，服務(wù)層有著暴露在YouNow.Api命名空間的登錄函數(shù)。

YouNow.Api.login() 
  .done(function (loginData) { 
    // Do what you need with the login data 
  }) 
  .fail(function (errorMsg) { 
    // Handle the error as you wish 
  }); 

注意：為了實現(xiàn)JS服務(wù)層，如果你不喜歡JQuery的回調(diào)模板，你可以替換用于接收成功/失敗回調(diào)的函數(shù)。我個人是喜歡這樣鏈式/管道的回調(diào)方式和標準接口。對于不喜歡這種方式的人，我也說一句你好。

聽起來不錯，不是嗎？

優(yōu)點：對于每一個YouNow.Api命名空間內(nèi)的結(jié)點，服務(wù)層younow.js將會有一個關(guān)于預(yù)期參數(shù)和被隱藏的復(fù)雜機制的文檔說明。尤其是使用服務(wù) 的用戶不用去擔(dān)心這個請求是GET還是POST，是通過CDN返回還是我們直接發(fā)送的，更不用擔(dān)心怎樣去構(gòu)建URL和如何處理jsonp數(shù)據(jù)。對于一個單 點來說，所有的后臺交互都是孤立的。

缺點：這個文件的增長迅速，幾乎超出你的想象。對于每一次后臺調(diào)用，我們需要一個增加新的YouNow.Api的結(jié)點。你可以抽象業(yè)務(wù)到helper函數(shù) 中來處理響應(yīng)，jsonp，cdn地址和$.ajax調(diào)用。然而，對于一個應(yīng)用來說，這個文件已經(jīng)達到40kb了。每一個應(yīng)用有自己的API結(jié)點集，每一 個都和younow.js交互。這對于維護來說是非常困難的。

現(xiàn)在想象一下，一個簡單的小應(yīng)用程序，如媒體播放器（ 例如一個JS的包裝器，JWPlayer的初始器）。它可能需要一個或兩個接口（登錄的接口和 檢索廣播信息的接口）。那么它必須下載整個40KB的數(shù)據(jù)包。

另一種實現(xiàn)1：為每個應(yīng)用程序分配一個服務(wù)層

常規(guī)的服務(wù)層可以是簡單的輔助函數(shù)的關(guān)鍵集合 （ajax，CDN，約定）， 每一個應(yīng)用程序在加載自身的服務(wù)層函數(shù)都將繼承YouNow.Api命名空間。

好處：這解決了主服務(wù)層不斷膨脹的問題。

好處：堅持什么時候以及如何擴展一個應(yīng)用程序的命名空間的原則，該解決方案可以清晰地擴展出多種應(yīng)用程序。

缺點：每一個應(yīng)用程序的個性化服務(wù)層可能變得非常臃腫。

缺點：如果兩個應(yīng)用程序都對同一個端點接口有共同的需求時，怎么辦？

// loginservice.js 
YouNow.Mixins.LoginService = { 
  login: function () {}, 
  logout: function () {} 
}; 
  
// broadcastservice.js 
YouNow.Mixins.BroadcastService = { 
  get: function () {}, 
  delete: function () {} 
}; 

另一種實現(xiàn)3：完全脫離服務(wù)層。將交互轉(zhuǎn)移到模塊內(nèi)完成

因為服務(wù)層的存在，想要和后臺進行交互的Backbone模塊只需要簡單的調(diào)用YouNow.Api離得函數(shù)就行?，F(xiàn)在這些模塊的實現(xiàn)是精簡的，但是你也能夠理解這些模塊其實不必傳輸自己的數(shù)據(jù)到別的地方。感覺就像是模塊應(yīng)該擁有那種功能。

完全脫離服務(wù)層，我們將會有一個擁有登陸/登出功能的用戶模塊和完全實現(xiàn)（或許是基于基本模塊的擴展，這樣我們能夠脫離CDN和ajax helper）。

優(yōu)點：各模塊擁有適當?shù)墓δ堋?/p>

缺點：隨著時間推移，越來越多的函數(shù)充斥著這個模塊。不是很確定這是否是一個缺點，因為對于“胖模型”來說，這也許就是一個優(yōu)點。

【更新】缺點：如果小的應(yīng)用想要實例化你的模塊現(xiàn)在需要Backbone（或者其他你在使用的框架）和它的依賴模塊，很不幸，將會為模塊的臃腫付出點代價，但是這可以作為你的系統(tǒng)統(tǒng)一化的一個折中方案。

任何想要使用登陸/登出功能的應(yīng)用都必須要實例化一個用戶模塊。這并不令人討厭。舉個例子，多媒體播放器應(yīng)用需要登陸一個用戶。那么現(xiàn)在有一個你的用戶,是一個用戶模塊的實例?，F(xiàn)在就可以調(diào)用它的登陸功能了。與之相比，不用去直接調(diào)用YouNow.Api.login()。

優(yōu)點：服務(wù)層變成了一些了經(jīng)過封裝的結(jié)點。數(shù)量的增長將會體現(xiàn)在兩個方面：封裝的數(shù)量和函數(shù)的數(shù)量。單層結(jié)構(gòu)只會在一個方面增長，所以這個方案有更好的伸縮性。

我現(xiàn)在正在想彌補這個方案的缺點，這也成為第三種最好的實現(xiàn)方式，但是我十分喜歡這種方式；通過下面的第三種實現(xiàn)方式，它修復(fù)了模塊的過度膨脹問題。

如果你發(fā)現(xiàn)這個方法的巨大缺陷，請給我留言。

通過上面的第二種實現(xiàn)方式（封裝方式），用戶模塊將不會擁有登錄/登出功能。反而，它將會封裝登錄服務(wù)，也許使用Cocktail.js——我也是這個項目的維護者之一;)。

這可以間接的訪問。我的意思是，你查看用戶模塊的定義，找不到登錄/登出方法。那么如何一眼看出用戶模塊有那中功能呢？從技術(shù)上說，我們傳遞數(shù)據(jù)到另一個服務(wù)，登錄服務(wù)獲得在封裝好的用戶模塊的數(shù)據(jù)，這樣就實現(xiàn)了用戶模塊自己的登錄功能。

什么是最好的解決方案？

我認為解決方案其實就是實現(xiàn)方式2和3的混合體。

在目前，服務(wù)層是一個好的想法，但是不能滿足復(fù)雜應(yīng)用的伸縮性。目前，我已經(jīng)遷移到胖模塊的實現(xiàn)（第三種方式），但是還沒搭配使用分組封裝（第二種方式）。

或許還有別的實現(xiàn)思路？

原文鏈接：http://www.oschina.net/translate/large-scale-javascript-a-monolithic-service-layer