先後端參數校驗統一處理方案

前端參數校驗方案

前言

由於我自身是後端大數據平臺開發的，由於前端資源比較缺，因此作了全棧開發工程師。前端技術方案選擇了比較簡單和容易入門的vue，基礎組件使用ele的基礎組件，圖標類的就是v-chart,echart,g2,g6都用，圖表類的使用順序優先級也是從前日後的。下面我給出相關的技術框架的連接，供你們參考。

• element基礎組件,基本可知足90%的需求,點擊連接看element官方文檔
• v-chart圖表組件，基本可知足90%的需求，點擊查看v-chart官方文檔
• echart圖表組件，也比較全面，但我的偏心v-chart,點擊查看echart
• g2圖表組件，阿里支付寶作的，用的少，點擊查看g2官方文檔
• g6圖表組件，阿里支付寶作的，用的比較少，血緣組件是基於g6作的，點擊查看g6官方文檔

表單校驗

咱們常常有一些需求，就是前端在向後端提交請求的時候，須要對提交的表單的字段進行校驗，好比表名或者名字字段，不能爲空，最大不能超過多少字符等這種需求，這種需求後端也要作校驗，前端爲了有一個好的體驗，也是要作校驗的，省的用戶辛辛苦苦填了那麼久的信息，到最後廢掉了，還要經過後端接口來看參數不合法的信息，體驗很差。

表單組件咱們基本是使用ele的表單組件，用起來簡單，也支持表單校驗功能，但每每咱們的需求遠比官網提供的例子要複雜的多，下面我總結了幾個需求要注意的地方，也就是參數校驗容易不生效的地方：

• form沒有綁定rules，form的model和參數裏面的對象綁定不一致。
• form裏記得要填寫ref，關聯該form，而後在提交的函數裏記得要寫this.$refs['form'].validata((valid)=>{});這樣，若是不寫的話，即便校驗失敗，仍是會向後提交請求的。
• 若是表單裏的要校驗的字段沒有提早定義好，或者是整個對象直接複製給form，這裏也容易不生效或者不許確的問題，這裏特別要注意賦值和深拷貝。

參數校驗體驗優化

在開發前端過程當中，有時候出現了輸入框從新賦值後，老的校驗結果還在，以致於體驗很很差，經過其餘操做，前端代碼改變賦值，而不是界面操做改變賦值的，這時候change和blur事件都觸發不到，老的校驗結果還赤裸裸的展現在那裏。舉個例子：

咱們在建表的時候要求表名不能爲空，咱們設置的校驗時間是blur（後來發現設置成change效果同樣）,咱們不輸入任何東西，而後離開，這是表名不能爲空的校驗是生效的，以下圖所示：

咱們點擊右上角的DDL建表，在裏面輸入一段sql以後，點擊解析，解析成功以後，會把解析出來的值覆蓋到表單裏面的表名和字段名，此時注意，表名的字段裏的值此時是符合咱們的規則的，可是上次的校驗結果還在，用戶還須要把鼠標放在輸入框裏，而後離開輸入框點擊一下，纔會從新觸發校驗，這樣的用戶體驗超級很差。

因此要研究如何解決這個問題，功夫不負有心人，研究ele的api的時候，實際上是有相關的api的，能夠清除上次的校驗結果。

解決方案

如上圖所示，clearValidate就是清除表單項的上次校驗結果，這裏使用參數的，你們用的時候要記住，若是直接調用this.$refs['form'].clearValidate()是清楚表單項全部表單項的上次校驗結果，若是隻須要清楚特定表單項的老的校驗結果，須要將要清除的表單項名字集合填進去便可。好比我會從新給庫名和表名賦值，只須要除楚這二個表單項的舊的校驗結果便可。

後端參數校驗方案

後端開發咱們使用springBoot或者springMvc進行開發的，也須要對參數進行校驗，好比修改的時候id不爲空啊，名稱不能爲空等，雖然這些靠前端能夠保證一些，可是別人也能夠繞過前端，直接請求你的後端接口，故意將參數穿的不規範，來破壞你的系統，將你的磁盤用日誌打滿等各類操做。由於即便在前端已經使用參數校驗進行了限制，爲了嚴謹性，仍是須要在後端作參數校驗的。固然能夠在代碼中針對每一個參數進行代碼校驗，不爲空啊，要大於0啊，字符串長度限制啊，後來就會發現只是參數校驗代碼就會幾百行了，嚴重影響了業務邏輯，並且在不一樣的方法裏面可能還會有重複的代碼等。針對這種問題，咱們可使用基於註解的方式進行參數校驗。

註解的範圍看我的習慣，若是你的service是隻提供給controller使用，沒有對外提供rpc服務，那麼你的參數校驗層在controller層徹底沒有問題，可是若是你的service服務若是有對外提供rpc服務，也能夠考慮將校驗加載service的接口上，這樣更能保證代碼的健壯性。

後端參數分爲二種，單個基本類型的包裝類，好比Long id,String name這種；還有一種是自定義對象TableApproveBO，咱們可能須要該對象裏面的某些值進行校驗。下面分別爲你們介紹：

單個基本類型的包裝類進行校驗

注意二點：須要在類上方加上validated註解，而後在對應的方法處加上校驗規則便可。以下圖所示：

自定義對象的校驗

自定義對象可能用在不一樣的場景，校驗規則不同，好比新增申請單的時候要求id能夠爲null，可是修改申請單的時候就必需要求修改的申請單的id不能爲空，可是兩者又是使用的同一個業務對象，這時候咱們就是須要使用分組校驗了。具體步驟以下：

定義校驗分組

• 首先咱們要定義爲了分組校驗所使用的分組，其實就是一些空的接口。

  

• 而後在業務對象上定義校驗規則和校驗規則所生效的分組，若是不定義分組，則默認全部分組都生效。

  

• 最後在須要校驗的方法上去加上校驗所使用的分組，而後參數校驗規則就會生效了。

  

• 爲了給前端一個友好的提示，須要對參數校驗不知足拋出的異常進行統一的處理，使不知足的規則具備易讀性，你們能夠看到我針對參數校驗拋出的異常定義了二個異常處理器，由於不一樣的參數校驗框架，跑出的異常不同，並且拋出異常裏面封裝的對象格式不同。由於我使用了多個參數校驗框架，原生的validate-api拋出的是ConstraintViolationException，可是其支持的校驗的規則有限，好比針對字符串只支持notNull，可是咱們其實想的是NotEmpty，就是不只僅是null，還不能是空字符串。這以後就要使用spring或者hibernate擴展的校驗，這時候每一個框架校驗拋出的異常就不同，須要作不一樣的處理。

  

遺留問題

還有一種狀況就是自定義對象內的二個字段相互依賴校驗這種狀況，當前尚未合適的方案，就是a字段的校驗邏輯依賴於b字段的取值，這種校驗需求我仍是放在代碼裏面做爲邏輯的的一部分進行校驗，還沒找到更好的校驗方案，若是你們又比較好的方案，能夠一塊兒分享。 字段a取值爲1的時候，b值必須爲空，字段a取值爲0的時候，b值不能爲空，就是這種校驗，歡迎你們一塊兒探討。