java前後端分離
一、前後端分離,整體流程
二、前端:
整體採用HTML+VUE。
2.1、路徑規範:
js獲取rootPath,然後定義ctx。
頁面中js的引入使用document.write。整體類似傳統jsp中的ctx。
一個業務的html檔案和js檔案放在同一個資料夾下,如下圖。
2.2、快取使用
前端session: 最低支援IE8 Chrome5
sessionStorage--針對一個 session 的資料儲存(關閉視窗,儲存的資料清空)。基於H5 大小5M;
localStorage--生命週期是永久,這意味著除非使用者顯示在瀏覽器提供的UI上清除,否則這些資訊將永遠存在。(因為是永久,後端的token要有時間控制)
2.3、前端引數傳遞
通過按鈕直接調轉html頁面的情況下,因為不經過後臺,跳轉時引數傳遞採用如下方式。parseQueryString()是擷取url引數的js方法,將url後面的所有引數轉換成obj物件, 在新的頁面中可以直接使用。
2.4、檔案上傳問題
通過jquery的ajax上傳。
有必要可以將檔案上傳單獨部署一臺伺服器,避免網路導致業務系統訪問速度。
2.5、公共標籤
2.5.1、分頁標籤
後端將現有的分頁標籤改造下,將生成的html通過分頁查詢的介面一同傳送到前臺。
2.5.2、前端格式化
jsp中實現時間的dateFormat,字串的substring等格式化標籤可以通過VUE的filter來實現。
2.6、資料校驗
前端資料合法性校驗?結構錯誤,空值等
類似form表單的validate。支援一些常用的規則,否則js裡面if可能會比較多。
2.7、資料校驗
請求超時,ajax:timeout。
三、後端:
3.1、介面規範:
提供線上的api查詢功能,定義好介面說明,介面url,請求引數,相應引數,請求示例,相應示例,錯誤碼說明等。
介面提供線上測試功能,後期上線後可提供給運維人員使用。
支援GET,POST兩種呼叫方式
3.1.1、預設提供方法
list方法 | get | 引數 | 是否必填 |
code | 否 | ||
name | 否 | ||
page | 是 | ||
getByFV | get | 引數 | 是否必填 |
field | 是 | ||
value | 是 | ||
edit | post | 引數 | 是否必填 |
id | 是 | ||
save | post | 引數 | 是否必填 |
物件 | 是 | ||
delete | post | 引數 | 是否必填 |
id | 是 |
3.1.2、統一響應
{ "result": {
"paramA":"V1",
"paramB":"V2"
},
"isSuccess": true,
"token": "(userId+時間)&加密",
"messageCode": "訊息碼",
"message": "說明"
}
3.1.2、錯誤定義:
@ControllerAdvice @ExceptionHandler
錯誤碼 | 錯誤描述 | 解決方案 |
1001 | 缺少引數 | 請核對引數 |
1002 | 引數錯誤 | 請核對引數型別,長度,是否必填 |
2001 | Token加密驗證失敗 | 詳見加密規則 |
2002 | Token超時 | 重新登入 |
2003 | 未登陸 | 請先登陸 |
3001 | SysException | 系統常見錯誤,具體請檢視介面返回message |
3.2、安全
3.2.1、token驗證
token為“userId+時間”,用base64加密。後端請求前需要對token進行攔截,驗證token是否過期。為保證處理效率,token存放在redis中,超時後需要重新生成並通知前段。
3.2.2、引數驗證
在執行後端介面前,需要對傳遞的引數進行型別,長度和是否必填驗證,如果引數不符合介面要求,直接返回相應錯誤。
3.2.3、跨域解決
CorsFilter。
3.3、開發規範
後端按“服務模組化”進行開發。
3.3.1、介面事務規則
涉及到事務的操作,都實現一次呼叫。查詢等不涉及事務的按最小粒度劃分,除特殊情況,後端不提供交叉查詢功能(即一個查詢介面不查兩張表)。
例如:刪除角色時,需要先將和使用者的關聯刪除,再將角色刪除。後端需要提供一個刪除角色的api,對應的service中將關聯資料和本身都刪除。避免前端進行兩次操作,簡化前端開發,也避免事務問題。
3.3.2、service編碼規範:
A、controller,service中只允許有自己模組的manager,需要呼叫其他模組的相關操作,只可引入其他模組的service,不可直接引入manager。
B、一個程式碼塊中,不可出現連續兩行同時呼叫一個service的方法。需要在service中合併後一次呼叫。
3.4、spring狀態機
類似供方稽核業務,整個流程中涉及狀態較多,狀態轉換控制複雜的情況,使用spring stateMachine。
開發過程中無需直接修改欄位,通過事件機制,對要修改的資料發起相應事件,有系統控制狀態流轉,避免狀態錯亂。
3.5、快取使用
後端引入redis作為快取資料庫。需要存放到當中的物件有:loginSession,userToken,核心資料。
注意點:A、key避免重複
B、設定失效時間,並打散失效時間,避免集中失效。
C、使用連線池和批量操作來提高效率。mget,mset。
D、避免多個應用使用一個redis,按業務拆分。
3.6、檔案上傳
採用nginx+fastdfs形式。檔案的下載或線上檢視,可通過nginx服務直接操作,無需消耗jboss資源。
3.7、gzip壓縮
減少後端伺服器的網路壓力。
3.8、@ResponseBody
ResponseBodyAdvice。
為方便轉json,專案裡一些物件中存在一些特殊的屬性需要特殊處理。
1.dict中的parent。這個欄位轉json時需要忽略,否則會一直找根節點,json string會特別長。
2.Date型別的欄位。需要制定格式。
3.9、springCache
通過springCache提供的註解@Cacheable,@CacheEvict等,將service方法和redis結合起來,方便redis的呼叫,程式更加簡潔明瞭。存放的資料有:token,loginSession,userAuth等。