單頁面應用

爲了簡單明瞭地理解什麼是單頁面應用，咱們先對比一下傳統的網頁應用。如圖一所示在傳統的web應用中：

• 客戶端向服務器發送http請求
• 服務器獲取請求並做出響應。這個過程具體是先由控制器（control）作出路由的分發，匹配到相應的數據服務（model）而後結合這個數據服務生成一個template即HTML文檔，這個template就是control的執行結果
• 服務器會將這個HTML文檔（視圖）返回給客戶端
• 客戶端將HTML文檔渲染到頁面

           

                                                               圖一                                                                               

單頁應用不必定就是MV*，用原生JavaScript也能夠作單頁應用。單頁應用的本質我理解是咱們的一個頁面就像一個客戶端程序同樣能夠實現各類各樣的複雜的交互，包括與用戶的交互、與服務端的交互等等。從另外一個角度看，單頁應用也有一個與以前的web頁面造成對比的性質。

單頁應用的原理如圖二所示，明顯看到單頁應用將本來存在於server的MVC搬到了client端。具體包括：

• C：控制器中的路由分發，即在瀏覽器端直接響應瀏覽器地址的變化，分發到對應的路由，向用戶呈現對應的界面。
• V：以小塊組件爲功能元件，相似於傳統網頁中的 Ajax 組件，單頁應用以小的組件爲功能元件，在路由變化時，再也不刷新整個頁面，而是組合這些小的組件，替換變化的部分。
• M：數據層前置，與 Ajax 組件一個明顯的區別是，單頁應用在瀏覽器端一般有一層實實在在的數據層，而服務端則退化成了徹底的數據 API。瀏覽器端的數據層會封裝服務端 API，供上層的視圖層調用。

                                                                 圖二

SPA所解決的問題

以上兩種對求情的處理方式中，傳統的處理方式中雖而後端應用了MVC模式，代碼可維護性獲得明顯好轉，架構層面讓開發者懂得什麼代碼應該寫在什麼地方。可是這種項目架構還存在不少不足：

• 傳統的web應用對路由的處理方式簡單粗暴，頁面由 JSP、PHP 等工程師在服務端生成，瀏覽器負責展示。基本上是服務端給什麼瀏覽器就展示什麼，展示的控制在 Web Server 層。
• 另外，因爲瀏覽器端只是一個展示層，當頁面功能有所變化的時，頁面就刷新，這會致使資源的浪費，用戶須要花費額外的時間等待頁面刷新，用戶體驗不佳。

出了問題方要改正，SPA的出現真正解決了上述問題。

具體的解決方案:

       首先路由分爲兩種，前端路由與後端路由。Web 服務會接收到請求後，會先解析 URI 中的後端路徑（即表明整個應用的父路徑）並將後端路由映射到對應的處理邏輯，這部分的路由分發僅分發到應用級別，沒有映射到具體頁面。對於路徑中剩下的的前端路由，web服務器選擇忽略，這部分的前端路由分發就已經具體到應用下的特定頁面了。 JavaScript 是能夠經過 window.location.hash 讀取到到前端路由的。

• SPA將應用下的子路由的前端化，實現了同一應用下的子路由的分發權置於瀏覽器端。
• 讀取到路徑加以解析以後就能夠響應不一樣路徑的邏輯處理。進一步匹配到具體的組件的替換，而不是刷新整個頁面。
• 先後端職責很清晰。前端工做在瀏覽器端，後端工做在服務端。前端能夠本地開發。後端專一於業務邏輯的處理：提供初始的 HTML 、提供 API Server 讓前端框架能夠取得資料用於前端 template。先後端數據都須要經過AJAX同步、提交。

SPA的不足

• 首屏加載時間長：在首屏中須要加載大量的靜態資源
• 全異步，對 SEO 不利。每每還須要服務端作同步渲染的降級方案。
• 性能並不是最佳，特別是移動互聯網環境下。

參考連接

MVC、MVP、MVVM

單頁面應用

Web 研發模式演變

前端路由與後端路由

前端路由與後端路由