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等。