方案根本要解決的問題是把數據和頁面剝離開來。應對這種需求的技術是現成的,前端採用靜態網頁相關的技術,HTML + CSS + JavaScript,經過 AJAX 技術調用後端提供的業務接口。先後端協商好接口方式經過 HTTP 提供,統一使用 POST 謂詞。接口數據結構使用 XML 實現,前端 jQuery 解析 XML 很方便,後端對 XML 的處理工具就更多了……後來因爲後端 JSON庫(好比 Newtonsoft JSON.NET、jackson、Gson 等)崛起,前端處理 JSON 也更容易(JSON.parse() 和 JSON.stringify()),就將數據結構換成了 JSON 實現。api
這種架構從本質上來講就是 SOA(面向服務的架構)。當後端不提供頁面,只是純粹的經過 Web API 來提供數據和業務交互能力以後,Web 前端就成了純粹的客戶端角色,與 WinForm、移動終端應用屬於一樣的角色,能夠把它們合在一塊兒,統稱爲前端。之前的一體化架構須要定製頁面來實現 Web 應用,同時又定義一套 WebService/WSDL 來對 WinForm 和移動終端提供服務。轉換爲新的架構以後,能夠統一使用 Web API 形式爲全部類型的前端提供服務。至於某些類型的前端對這個 Web API 進行的 RPC 封裝,那又是另一回事了。安全
經過這樣的架構改造,先後端實際就已經分離開了。拋開其它類型的前端不提,這裏只討論 Web 前端和後端。因爲分離,Web 前端在開發的時候壓根不須要了解後端是用的什麼技術,只須要後端提供了什麼樣的接口能夠用來作什麼事情就好,什麼 C#/ASP.NET、Java/JEE、數據庫……這些技術能夠通通不去了解。然後端的 .NET 團隊和 Java 團隊也脫離了邏輯無關的美學思惟,不須要面對美工精細的界面設計約束,也不須要在思考邏輯實現的同時還要去考慮頁面上怎麼佈局的問題,只須要處理本身擅長的邏輯和數據就好。前端框架
前端傾向於呈現,着重處理用戶體驗相關的問題;後端則傾處於業務邏輯、數據處理和持久化等。在設計清晰的狀況下,後端只須要以數據爲中心對業務處理算法負責,並按約定爲前端提供 API 接口;而前端使用這些接口對用戶體驗負責。
2. 先後技術分離
前端能夠不用瞭解後端技術,也不關心後端具體用什麼技術來實現,只須要會 HTML/CSS/JavaScript 就能入手;然後端只須要關心後端開發技術,除了省去學習前端技術的麻煩,連 Web 框架的學習研究都只須要關注 Web API 就好,而不用去關注基於頁面視圖的 MVC 技術(並非說不須要 MVC,Web API 的接口部分的數據結構呈現也是 View),不用考慮特別複雜的數據組織和呈現。
後端只提供 API 服務,不考慮頁面呈現的問題。實現 SOA 架構的 API 能夠服務於各類前端,而不只僅是 Web 前端,能夠作到一套服務,各端使用;同時對於前端來講,不依賴後端技術的前端部分能夠獨立部署,也能夠應於 Hybrid 架構,嵌入各類「殼」(好比 Electron、Codorva 等),迅速實現多終端。
採用傳統的 Cookie/Session 認證方案並不是不可行,只不過有一些限制。若是前端部分和後端部分同源,好比頁面發佈在 http://domain.name/,而 Web API 發佈在 http://domain.name/api/,這種狀況下,原來的一體式 Web 方案所採用的 Cookie/Session 方案能夠直接遷移過來,毫無壓力。可是若是前面發佈和 API 發佈不一樣源,這種方法處理起來就複雜了。
先後分離以後,前端的測試將以用戶體驗測試和集成測試爲主,然後端則主要是進行單元測試和 Web API 接口測試。與一體化的 Web 應用相比,多了一層接口測試,這一層測試能夠徹底自動化,一旦完成測試開發,就能在很大程度上控制住業務處理和數據錯誤。這樣一來,集成測試的工做量會相對單一也容易得多。
前端測試的工做相對來講減輕不了多少,先後分離以後的前端部分承擔了原來的集成測試工做。可是在假設 Web API 正確的狀況下進行集成測試,工做量是能夠減輕很多的,用例能夠只關注前端體驗性的問題,好比呈現是否正確,跳轉是否正確,用戶的操做步驟是否符合要求以及提示信息是否準確等等。
對於用戶輸入有效性驗證這部分工做在項目時間緊迫的狀況下甚至均可以徹底拋給 Web API 去處理。無論是否先後端分離,Web 開發中都有一個共識:永遠不要相信前端!既而後端必須保證數據的安全性和有效性,那麼前端省略這一步驟並不會對後端形成什麼實質性的威脅,最多隻是用戶體驗差一點。可是,若是先後端都要作數據有效性驗證,那必定要嚴格按照文檔來進行,否則很容易出現先後端數據驗證不一致的狀況(這不是先後分離的問題,一體化架構一樣存在這個問題)。
小結
總的來講,先後分離所帶來的好處仍是很明顯的。可是具體實施的時候須要一個全新的思考方式,而不是基於原有一體化 Web 開發方式來進行思考。先後分離的開放方式將開發人員從複雜的技術組合中解放出來,你們均可以更專一於本身擅長的領域來進行開發,但同時也對先後端團隊的溝通交流提出了更高的要求,先後端團隊必需要一同設計出相對穩定的 Web API 接口(這部分工做其實無論是否先後端分離都是少不了的,只是先後分離的架構對此要求更高,更明確地要求接口不僅存在於人的記憶中,更要文檔化、持久化)。