(一) 前後端分離的目的和作用

做Web開發也可以說是B/S架構開發，B端和S端從技術體系角度而言異構性很大，換而言之就是B端使用的技術和S端使用的技術不適於同一個體系，這樣的結果導致實際開發中，很難做到專業分工，如果專案開發過程中管控不到位，這樣的問題可能會影響到整個專案的開發質量，因此前後端分離的目的之一就是要做到專業化分工，提高專案的質量和開發效率。

隨著技術的發展，當下的Web開發形勢已經和以前有了很大的不同，早期的Web專案是一個封閉的專案，使用者從瀏覽器裡看到的頁面直到後臺資料庫都是在一個專案裡整合的，而現在Web系統的規模越來越大，中大型的Web系統是一個開放式的系統，開放型的系統使用者在瀏覽器發起的請求可能會轉發到外部的系統裡進行處理，或者是本地的系統和外部系統一起完成請求的處理，此外有的請求可能不會直接請求資料庫，而是請求快取伺服器，這些變化幾乎都是發生在Web系統的服務端，前後端耦合度很高的Web系統服務端的複雜度提升必然帶來了Web前端的複雜度的提升。因此Web前端從系統架構的角度也需要更加專業的管控，管控的作用之一就是前後端進行分離，降低前端對服務端的依賴性。

富客戶端應用的普及導致Web前端技術開發更加專業化，Web前端工程師成為一個獨立的技術崗位，Web前端開發技術的難度也越來越高，前後端的分離就是為Web前端開發營造一個良好的開發環境，不要讓前端工程師被一些不可控的外在因素所影響（例如：前後端的耦合性），最後導致前端不能專心致志做出更加好的作品。所以，前後端分離是讓前後端更加專業化，在技術和管理上將前端角色更加明確，更深入的挖掘前端開發的價值。

(二) 現有系統架構給前後端帶來的問題以及解決方法

上圖是目前大部分系統的架構圖，雖然有些系統採用分散式架構，層與層之間使用了遠端呼叫框架，但是本質上都逃不開上面這個架構設計。這張圖是一張比較合理的圖，在實際開發裡最常發生的事情就是控制層（Control）越過服務層（Service）直接處理下面的資源。

前後端耦合的問題主要發生在控制層（Control），控制層是前端和服務端互動的邊界，但是在開發過程中控制層（Control）和服務層（Service）常常混淆不清，這就是前後端耦合度高的重要原因。

因此要前後端解耦，就是要劃清控制層的邊界，控制層到底該屬於前端還是服務端，在MVC模式裡控制層作用是排程，控制層不是寫業務邏輯的地方，因此將大量業務邏輯寫到控制層其實是違背了MVC模式的思想，同時控制層是前端和服務端通訊的橋樑，其實控制層是參入了前端的工作任務，既然控制層要剝離業務操作同時控制層也要參入前端應用的開發，那麼將控制層歸為前端的一部分是完全合情合理合規的。

把控制層剝離了業務邏輯處理可能會讓人不知道如何開發了，我覺得有這種想法的人是開發時候沒有理解透MVC模式思想，程式設計隨意性大養成了壞習慣，這個就需要這些人一點點去適應技術新趨勢的發展。

前後端分離的終極目標應該是前端和服務端是完全獨立的專案，前端專案包含上圖裡的瀏覽器和控制層，服務端專案包括服務層、DAO層等等，前端專案和服務端專案以高效的遠端呼叫框架做通訊介質，專案開發時候前端專案做前端的事情，服務專案做服務端的事情，這樣就讓服務端開發的人員沒有機會在控制層亂寫程式碼了，保證了Web前端環境的純粹性，最後生產釋出也要獨立部署，這樣就達到了前後端真正解耦，但是前後端的溝通機制也是不可或缺的，我覺得它們之間的溝通使用高效能的遠端呼叫框架，前後端相互約定通訊報文格式。.

其實不管服務端還是前端巨集觀流程無非是輸入資料à資料處理à輸出資料，但是服務端要把心思花在資料處理上，前端要更多關心的是輸入輸出資料時候的使用者體驗操作，服務端開發最大的問題就是違背MVC原則，程式碼編寫的隨意性，而前端不管出於安全還是效能考慮，最好是儘量少牽涉業務。前端和後端通訊層的獨立，會將前後端進行真正的解耦，前面我講到前後真正問題就是前端和後端技術路線不一致，但是傳統Web開發裡前後端又要融為一體，這就導致前後端很難做到專業化分工，對於前端應該儘量弱化通訊級別的開發工作，前端通訊程式設計只要知道呼叫哪個介面，傳什麼引數，怎麼處理響應資訊就行了。這樣就能讓前端和後端實現真正的專業化。