（如果對SPA概念不清楚的同學可以先自行了解相關概念）
平時喜歡做點小頁面來玩玩，并且一直采用單頁面應用（Single Page Application）的方式來進行開發(fā)。這種開發(fā)方式是在之前一年做的一個創(chuàng)業(yè)項目的經(jīng)驗和思考，一直想寫篇博客來總結一下。
個人認為單頁面應用的優(yōu)勢相當明顯：
前后端職責分離，架構清晰：前端進行交互邏輯，后端負責數(shù)據(jù)處理。
前后端單獨開發(fā)、單獨測試。
良好的交互體驗，前端進行的是局部渲染。避免了不必要的跳轉和重復渲染。
當然，SPA也有它自身的缺點，例如不利于搜索引擎優(yōu)化等等，這些問題也有其相應的解決方案。
下面要介紹的這種方式可以說是一種模式或者工作流，和前端使用什么框架無關，也和后端使用什么語言、數(shù)據(jù)庫無關。不能說是The Best Practice，我相信經(jīng)過更多人的討論和思考會有A Better Practice。:)
下圖展示了這種模式的整個前后端及各自的主要組成：
看起來有點復雜，接下來會仔細地對上面每一個部分進行解釋?？赐瓯疚?，就應該能理解上圖中的各部件之間的交互流程。
把上圖的前端部分單獨抽出來進行研究：
前端中大致分為四種類型的模塊：
components：前端UI組件
services：前端數(shù)據(jù)緩存和操作層
databus：封裝一系列Ajax操作，和后端進行數(shù)據(jù)交互的部件
common/utils：以上組件的共用部件，可復用的函數(shù)、數(shù)據(jù)等
component指的是頁面上的一個可復用UI交互單元，例如一個博客的評論功能：
我們可以把博客評論做為一個組件，這個組件有自己的結構（html），外觀（css），交互邏輯（js），所以我們可以單獨做一個叫comment的component，由以下文件組成：
comment.html
comment.css
comment.js
（每個component可以想象成一個工程，甚至可以有自己的README、測試等）
一個component可以依賴另外一個component，這時候它們是父子關系；component之間也可以互相組合，它們就是兄弟關系。最后的結果就類似DOM tree，component可以組成components tree。
例如，現(xiàn)在要給這個博客添加兩個功能：
顯示評論回復。
鼠標放到評論或者回復的用戶頭像上可以顯示用戶名片。
我們構建兩個組件，reply和user-info-card。因為每個comment都要有自己的回復列表，所以comment組件是依賴于reply組件的，comment和reply組件是嵌套關系。
而user-info-card可以出現(xiàn)在comment或者reply當中，并且為了以后讓user-info-card復用性更強，它應該不屬于任何一個組件，它和其他組件是組合關系。所以我們就得到一個簡單的componenets tree：
怎么可以做到鼠標放到評論和回復的用戶頭像上顯示名片呢？這其實牽涉到組件之間是如何進行通信的問題。
最佳的方式就是使用事件機制，所有組件之間可以通過一個叫eventbus通用組件進行信息的交互。所以，要做到上述功能：
user-info-card可以在eventbus監(jiān)聽一個user-info-card:show的事件。
而當鼠標放到comment和reply組件的頭像上的時候，組件可以使用eventbus觸發(fā)user-info-card:show事件。
user-info-card:
var eventbus = require("eventbus")eventbus.on("user-info-card:show", function(user) { // 顯示用戶名片})comment or reply:
var eventbus = require("eventbus")$avatar.on("mouseover", function(event) { eventbus.emit("user-info-card:show", userData)})components之間用事件進行通信的優(yōu)勢在于：
組件之間沒有強的依賴，組件之間被解耦。
組件之間可以單獨開發(fā)、單獨測試。數(shù)據(jù)和事件都可以簡單的進行偽造進行測試（mocking）。
總結：component之間有嵌套和組合的關系，構成components tree；component之間通過事件進行信息、數(shù)據(jù)的交換。
component的渲染和顯示依賴于數(shù)據(jù)（model）。例如上面的評論，就會有一個評論列表的model。
comments: [ {user:.., content:.., createTime: ..}, {user:.., content:.., createTime: ..}, {user:.., content:.., createTime: ..}]每個評論的component會對應一個comment（comments數(shù)組中的對象）進行渲染，渲染完以后就會正確地顯示在頁面上。
因為可能在其他component中也會需要用到這些數(shù)據(jù)，所以comment component不會自己直接保存這些comment model。這些model都會保存在service當中，而component會從service拿取數(shù)據(jù)。components和services之間是多對多的關系：一個component可能會從不同的services中拿取數(shù)據(jù)，而一個service可能為多個components提供數(shù)據(jù)。
services除了用于緩存數(shù)據(jù)以外，還提供一系列對數(shù)據(jù)的一些操作接口。可以提供給components進行操作。這樣的好處在于保持了數(shù)據(jù)的一直性，假如你使用的是MVVM框架進行component的開發(fā)，對數(shù)據(jù)的操作還可以直接對多個視圖產(chǎn)生數(shù)據(jù)綁定，當services中的數(shù)據(jù)變化了，多個components的視圖也會相應地得到更新。
總結：services是對前端數(shù)據(jù)（也就是model）的緩存和操作。
而services中緩存的數(shù)據(jù)是從哪里來的呢？當然也許想到的第一個方案是在services中直接發(fā)送Ajax請求去服務器中拉去數(shù)據(jù)。而這里建議不直接這樣做，而是把各種和后端的API進行交互的接口封裝到一個叫databus的模塊當中，這里的databus相當于是“對后端數(shù)據(jù)進行原子操作的集合”。
如上面的comment service需要從后端進行拉取數(shù)據(jù)，它會這樣做：
var databus = require("databus")var comments = nulldatabus.getAllComments(function(cmts) { // 調用databus方法進行數(shù)據(jù)拉取 comments = cmts})而databus中則封裝了一層Ajax
databus.getAllCommetns = function(callback) { utils.ajax({ url: "/comments", method: "GET", success: callback })}這樣做是因為，不同的services之間可能會用到同樣的接口對后端進行操作，把操作封裝起來可以提高接口的復用性。注意，如果databus中的某些操作不涉及到servcies的數(shù)據(jù)，這操作也可以被components所調用（例如退出、登錄等）。
總結：databus封裝了提供給services和component和后端API進行交互的接口。
這兩個模塊都可以被其他組件所依賴。
common，故名思議，組件之間的共用數(shù)據(jù)和一些程序參數(shù)可以緩存在這里。
utils，封裝了一些可復用的函數(shù)，例如ajax等。
所有組件（特別是components之間）的通過事件機制進行數(shù)據(jù)、消息通信的接口?？梢院唵蔚厥褂?a target="_blank" rel="nofollow">EventEmitter這個庫來實現(xiàn)。
傳統(tǒng)的網(wǎng)頁頁面一般都是由后端進行頁面的渲染，而在我們的架構當中，后端只渲染一個頁面，其后，后端只是相當于一個Web Service，前端使用Ajax調用其接口進行數(shù)據(jù)的調取和操作，使用數(shù)據(jù)進行頁面的渲染。
這樣的好處就是，后端不僅僅能處理Web端的頁面的請求，而且處理提供移動端、桌面端的請求或者作為第三方開放接口來使用。大大提高后端處理請求的靈活性。
后端對比起前端的架構來說會簡單很多，但是這只是其中一種模式，對于不同復雜程度的應用可能會做相應的調整。后端大概分為三層：
CGI：設置不同的路由規(guī)則，接受前端來的請求，處理數(shù)據(jù)，返回結果。
business：這一層封裝了對數(shù)據(jù)庫的一些操作，business可以被CGI所調用。
database：數(shù)據(jù)庫，進行數(shù)據(jù)的持久化。
例如上面的comments的例子，CGI可以接收到前端發(fā)送的請求：
var commentsBusiness = require("./businesses/comments")app.get("/comments", function(req, res) { // 此處調用comments的business數(shù)據(jù)庫操作 commentsBusiness.getAllComments(function(comments) { // 返回數(shù)據(jù)結果 res.json(comments) })})后端的API可以采用更規(guī)范的RESTful API的方式，而RESTful不在本文的討論范圍內。有興趣的可以參考Best Practices for Designing a Pragmatic RESTful API。
前后端的架構都基本清晰了，我們來看看文章開頭的圖：
看著圖來，我們總結一下整個前后端的交互流程：
前端向服務端請求第一個頁面，后端渲染返回。
前端加載各個component，components從services拿數(shù)據(jù)，services通過databus發(fā)送Ajax請求向后端取數(shù)據(jù)。
后端的CGI接收到前端databus發(fā)送過來的請求，處理數(shù)據(jù)，調用business操作數(shù)據(jù)庫，返回結果。
前端接收到后端返回的結果，把數(shù)據(jù)緩存到service，component拿到數(shù)據(jù)進行前端組件的渲染、顯示。
一個好的工作流可以讓開發(fā)事半功倍。上面的這種單頁面應用也有其相應的一種開發(fā)工作流，當然這種工作流也適合非單頁面應用：
進行產(chǎn)品功能、原型設計。
后端數(shù)據(jù)庫設計。
根據(jù)產(chǎn)品確定前后端的API（or RESTful API），以文檔方式紀錄。
前后端就可以針對API文檔同時進行開發(fā)。
前后端最后進行連接測試。
前后端分離開發(fā)。建議都可以采用TDD（測試驅動開發(fā)）的方式來單獨測試、單獨開發(fā)（關于Web APP測試這一塊可以單獨進行討論研究），提高產(chǎn)品的可靠性、穩(wěn)定性。
（完）
