先後端徹底分離的思考

網站開發歷程

一、雜合模式

早期的asp開發網站時期大可能是如此，
一個asp文件混合業務處理，頁面顯示，js動態交互；徹底雜合在一塊兒；

一個請求對應一個asp文件，業務邏輯解析，動態輸出html內容。

後期的php、早期的jsp也是如此模式；

 

二、webform模式

這個是微軟asp.net時期的一個方式，本質上是封裝html爲服務器控件，動態生成html及相關提交和狀態保持；

先後端分離，事件觸發模式；

出發點是好的，可是這個模式問題太多。

簡單的問題複雜化，致使你們學習成本增長，要單獨取學習下服務器控件，這個徹底背離了html簡單簡潔的原則。

致使各類代碼冗餘，開發代碼的靈活性也下降到不行。

隨着後來無刷新ajax技術流行，微軟漸漸也是放棄了這個提交submit的交互模式，儘管後來有scriptmanager等也是各類難受，

封裝到最後還不如直接用html來的科學，方便。

學習成本也是標高，和底層瞭解html背道而馳。

慢慢的就淡出了你們的視野。

 

三、模板引擎模式

一套獨立的模板語法，這個好多的都是獨立的模板引擎（包括如今微軟的razor其實也才如此，只能說mvc也是low）

大可能是基於本身開發的或者統一的模板引擎，將頁面顯示部分獨立出來到單獨html文件；

這個方式的好處多了取了，方便模板的統一管理，核心業務被單獨分離出去；模板只完成顯示任務；

服務器端完成頁面解析生成HTML內容返回給客戶端，

服務器端：數據+模板語法；

（說下asp.net mvc吧，路由機制真是太死板了。這個要表揚下nancy吧，人家的靈活性真是沒誰了。

mvc再也不基於aspx頁面的存在而是基於路由模式；

而後control的自動綁定model只能說太low，靈活性太差；增長減小字段就要重構一遍model；

view用一個集中的bag管理數據，也是難爲做者了。而後就是htmlHelper了，又是服務器控件的翻版。

只能說本意是好的，如此而已。徒增長學習成本）

 

四、先後端徹底分離模式

服務器端：完成業務邏輯處理，返回數據(json)給客戶端；微服務API；

客戶端：模板引擎（vue好像正火）+數據（json)

這個模式好處N多，

最大的好處就是一套API，無限終端（只要你的API服務器夠強大）

a、服務器減壓，顯示邏輯不須要客戶端組裝，徹底有客戶端js完成；

b、一套api接口能夠給各類客戶端調用，app、web，gui等等；

c、客戶端單獨部署、api單獨部署、甚至能夠多前端部署；

d、業務邏輯服務器，相對獨立的模塊能夠單獨部署開發；

e、獨立的認證服務器，基於auth2.0模式；單點登陸，統一認證；方便第三方調用集成；用戶+權限；

f、方便版本升級，多版本並存，請求路徑修改就好；API接口統一；

g、升級維護成本下降，界面只是完成顯示，修改不會影響到業務邏輯；要知道你們對美的要求真是突飛猛進。

h、方便單元測試，mvc模式解決了這個問題；

 

總結:

多終端時代，無疑微服務API是最科學的選擇。

服務器端漸漸只完成必須完成的工做，能不作的都分配到客戶端部分完成，這樣纔是最好的選擇。