大規(guī)模的JavaScript: 單一的服務層
當我在開始架構一個JS 應用的原型時，我總是嘗試把這些組件設計成既能被Backbone.js應用使用也能被一次性的腳本或者工程使用的結構。這些結構性的組件增長十分迅速，他們變得十分龐雜。在這篇文章中，我將會研究后端API服務層的動機，優(yōu)點，缺點以及建議或者頭腦風暴他們的代替實現方式。
后端API服務層
盡管你可能實現了你的后端API（MVC或者別的方式），但是記憶和重復實現API的細節(jié)是非常笨重的。當一個團隊成員說他們開發(fā)一些東西需要登錄功能，他們是需要重復造輪子還是你給他們一個預編譯的JS函數調用呢？
我希望建立一個名字為younow.js的JS客戶端來解決這些問題，這將允許任何JS應用和我們的后臺交互。有一個新增的需求需要登錄功能？不用擔心！ 只要調用YouNow.Api.login()并且綁定處理函數就行。在這個例子中，服務層有著暴露在YouNow.Api命名空間的登錄函數。
- YouNow.Api.login()
- .done(function (loginData) {
- // Do what you need with the login data
- })
- .fail(function (errorMsg) {
- // Handle the error as you wish
- });
注意：為了實現JS服務層，如果你不喜歡JQuery的回調模板，你可以替換用于接收成功/失敗回調的函數。我個人是喜歡這樣鏈式/管道的回調方式和標準接口。對于不喜歡這種方式的人，我也說一句你好。
聽起來不錯，不是嗎？
優(yōu)點：對于每一個YouNow.Api命名空間內的結點，服務層younow.js將會有一個關于預期參數和被隱藏的復雜機制的文檔說明。尤其是使用服務 的用戶不用去擔心這個請求是GET還是POST，是通過CDN返回還是我們直接發(fā)送的，更不用擔心怎樣去構建URL和如何處理jsonp數據。對于一個單 點來說，所有的后臺交互都是孤立的。
缺點：這個文件的增長迅速，幾乎超出你的想象。對于每一次后臺調用，我們需要一個增加新的YouNow.Api的結點。你可以抽象業(yè)務到helper函數 中來處理響應，jsonp，cdn地址和$.ajax調用。然而，對于一個應用來說，這個文件已經達到40kb了。每一個應用有自己的API結點集，每一 個都和younow.js交互。這對于維護來說是非常困難的。
現在想象一下，一個簡單的小應用程序，如媒體播放器（ 例如一個JS的包裝器，JWPlayer的初始器）。它可能需要一個或兩個接口（登錄的接口和 檢索廣播信息的接口）。那么它必須下載整個40KB的數據包。
另一種實現1：為每個應用程序分配一個服務層
常規(guī)的服務層可以是簡單的輔助函數的關鍵集合 （ajax，CDN，約定）， 每一個應用程序在加載自身的服務層函數都將繼承YouNow.Api命名空間。
好處：這解決了主服務層不斷膨脹的問題。
好處：堅持什么時候以及如何擴展一個應用程序的命名空間的原則，該解決方案可以清晰地擴展出多種應用程序。
缺點：每一個應用程序的個性化服務層可能變得非常臃腫。
缺點：如果兩個應用程序都對同一個端點接口有共同的需求時，怎么辦？
- // loginservice.js
- YouNow.Mixins.LoginService = {
- login: function () {},
- logout: function () {}
- };
- // broadcastservice.js
- YouNow.Mixins.BroadcastService = {
- get: function () {},
- delete: function () {}
- };
另一種實現3：完全脫離服務層。將交互轉移到模塊內完成
因為服務層的存在，想要和后臺進行交互的Backbone模塊只需要簡單的調用YouNow.Api離得函數就行。現在這些模塊的實現是精簡的，但是你也能夠理解這些模塊其實不必傳輸自己的數據到別的地方。感覺就像是模塊應該擁有那種功能。
完全脫離服務層，我們將會有一個擁有登陸/登出功能的用戶模塊和完全實現（或許是基于基本模塊的擴展，這樣我們能夠脫離CDN和ajax helper）。
優(yōu)點：各模塊擁有適當的功能。
缺點：隨著時間推移，越來越多的函數充斥著這個模塊。不是很確定這是否是一個缺點，因為對于“胖模型”來說，這也許就是一個優(yōu)點。
【更新】缺點：如果小的應用想要實例化你的模塊現在需要Backbone（或者其他你在使用的框架）和它的依賴模塊，很不幸，將會為模塊的臃腫付出點代價，但是這可以作為你的系統統一化的一個折中方案。
任何想要使用登陸/登出功能的應用都必須要實例化一個用戶模塊。這并不令人討厭。舉個例子，多媒體播放器應用需要登陸一個用戶。那么現在有一個你的用戶,是一個用戶模塊的實例?，F在就可以調用它的登陸功能了。與之相比，不用去直接調用YouNow.Api.login()。
優(yōu)點：服務層變成了一些了經過封裝的結點。數量的增長將會體現在兩個方面：封裝的數量和函數的數量。單層結構只會在一個方面增長，所以這個方案有更好的伸縮性。
我現在正在想彌補這個方案的缺點，這也成為第三種最好的實現方式，但是我十分喜歡這種方式；通過下面的第三種實現方式，它修復了模塊的過度膨脹問題。
如果你發(fā)現這個方法的巨大缺陷，請給我留言。
通過上面的第二種實現方式（封裝方式），用戶模塊將不會擁有登錄/登出功能。反而，它將會封裝登錄服務，也許使用Cocktail.js——我也是這個項目的維護者之一;)。
這可以間接的訪問。我的意思是，你查看用戶模塊的定義，找不到登錄/登出方法。那么如何一眼看出用戶模塊有那中功能呢？從技術上說，我們傳遞數據到另一個服務，登錄服務獲得在封裝好的用戶模塊的數據，這樣就實現了用戶模塊自己的登錄功能。
什么是最好的解決方案？
我認為解決方案其實就是實現方式2和3的混合體。
在目前，服務層是一個好的想法，但是不能滿足復雜應用的伸縮性。目前，我已經遷移到胖模塊的實現（第三種方式），但是還沒搭配使用分組封裝（第二種方式）。
或許還有別的實現思路？
原文鏈接：http://www.oschina.net/translate/large-scale-javascript-a-monolithic-service-layer
