轉自：http://www.cnblogs.com/sharpxiajun/p/3531665.html
最近研究servlet，看書時候書裏講到了c/s架構到b/s架構的演變，講servlet的書都很老了，現在的b/s架構已經不是幾年前的b/s架構，其實b/s架構就是web應用開發，對於這樣的架構我們現在應該考慮的是前端和後端的分離（注意：這裏的後端是指服務端）。
Web前端現在是一個獨立的技術工種，這個工種的產生主要是針對互聯網行業的需求，我在以前的文章裏曾經講到過，一個大型互聯網網站，例如想淘寶網，它絕對不是一個Web項目，而是一羣web項目的集合，那麼如果不在前端進行整合，這麼多web項目前端開發一定存在大量重複勞動，並且運維時候也存在難以統一管理的問題。本文假想一個面對需要前端資源整合的組織，如何做到前後端分離的解決思路。本文詳情如下：
(一) 前後端分離的目的和作用
做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開發裏前後端又要融爲一體，這就導致前後端很難做到專業化分工，對於前端應該儘量弱化通訊級別的開發工作，前端通訊編程只要知道調用哪個接口，傳什麼參數，怎麼處理響應信息就行了。這樣就能讓前端和後端實現真正的專業化。
做到了這些，就不會發生開發時候前後端邊界不清的問題了。
(三) 前後端分離的一些想法
本文主題應該是前後端分離，我上面的建議是個徹底方案，要革以前系統的命，對存量系統那該如何處理，答案還是重構代碼，想方設法逐步減少已經發現的前後端耦合度高的問題，這個跟我之前的建議就是小重構和大重構的區別，如果有人覺得我上面建議合適，前端組應該馬上提供一套這樣的框架出來，這樣後面的新系統就不會在循環前面的錯誤了。我覺得搭建這樣的框架不會太複雜的。
我上面的前後端分離的目的就是將前端資源整合爲一個整體，理清前後端的邊界，這些做完後，前端組裏該如何提升自己的能力了？
這時候要讓前端的東西項目化，工程化，前端技術不能再當做開發者的玩具，它也是需要大量的系統架構，開發規範，自動化壓縮混淆，自動化發佈，前端監控和分析，前端優化等等。
上面這些問題都很重要，也很專業，如果我有機會能參入這樣的事情，我還有個特別的建議，具體如下：
在一個企業內部，Web前端的組件，不管這個組件是UI層級，還是javascript開發層級，都脫離不了該企業業務產品的模式，其實看看像網易，新浪這樣的門戶網站的前端應用組件，它們用於做門戶很合適，但是用它來做企業應用軟件可能就不是太好使用，因此對於組件要有一個清晰的認識，我覺得可以把組件按業務場景分類，這裏我可以舉個例子，如果這個企業有給門戶使用的組件，而這個組件很適合門戶，應該把它歸爲門戶組件，如果某些組件適合做網站後臺管理的，那麼就列爲後臺管理組件，如果某些組件能跨多了業務場景則標記爲通用組件。
做分類的原因是爲了理清組件的應用邊界，這樣我們可以有針對性的積累和完善這些組件，有意識的開發相關的組件，最終形成一個針對某個業務組件的組件倉庫，這樣等新需求過來，Web前端的項目經理或Web前端的技術經理可以通過場景分析該需求需要使用那些現有的技術，需求裏的那些場景是要進行開發，新場景裏有沒有新開發的代碼能生成新的組件，這就可以做到有計劃有次序的積累。
Web前端的核心人員應該花更多精力去設計、積累、整理各種組件，通過實際業務需求去完善和豐富這些組件，最終達到組件可以覆蓋到全公司絕大多數場景，最終通過組件積累形成完善的Web前端開發規範，這樣的規範覆蓋面廣更加易於操作，對於企業而言Web前端開發流程就可以做到標準化，從而達到簡單培訓一些技術能力不高的開發人員就能完成相關的開發任務，同時也讓Web前端核心人員也能很好的把控項目的質量和進度。
以上就是我的一些前後端分離的想法，它是一個很宏觀的想法，沒有太多技術實現細節，如果這個想法如果針對存量系統，的確是一個顛覆性的方案，如果Web前端允許一切重頭來做，我個人覺得這還是很好的一個思路。前後端分離是Web前端專業化的萬里長征第一步，如果這一步做好，前端就有一套專屬自己的優質環境，那時候Web前端就會有更大的餘力做更優秀的工作，這就是我的願景。