在學生管理系統里，其中會有學生資訊采集的功能，程式結構不外乎下面的分層實作方式，
開發出來這個功能，我覺得大家都易如反掌了，
當然易如反掌，
OK，我要說的是資料校驗，以最簡單的非空校驗（例如：學生姓名不可為空）來說：
首先，前端頁面的表單要校驗，為空則不允許提交，非空則呼叫后端api介面來post資料，
其次，后端程式的controller里要校驗，為空則直接回傳錯誤提示，非空則呼叫StudentService類，
再次，StudentService類要校驗，為空則直接回傳錯誤提示，非空則在其他校驗通過后，進行資料的持久化，
上面的“再次”，在單體應用內不做校驗也可————而一旦是在RPC呼叫的情況下，是必須要做的，
那么，聰明的你，有沒有，或者曾經有沒有，忽視上面的幾處校驗呢？
你也許會說No. ————肯定會做校驗呀，
你也許還會說but why？————為什么要這么多處校驗呢？一個地兒校驗住不就完了嗎？
First，為什么前端要校驗？
--> 前端頁面校驗不通過時，則直接在頁面提示給用戶了，好處：①回應快，因為無須呼叫后端api，也減少了網路通信；②用戶體驗會好一些，
Second，前端已經校驗了，為什么后端還要校驗？
--> 正常情況下是不需要后端再校驗了，非正常情況下呢？例如，前端沒攔住，再例如，請求不是前端發過來的...
Third，為什么service類還要校驗？
--> 上面說了，如果是單體應用，你不校驗也行，而如果是局域網RPC服務之間呼叫的話，你還真要加上這個校驗，也是為了防止非正常情況的，
多次一舉？
實際企業應用開發中，類似的需要多處“重復”做的校驗包括：資料合法性校驗、資料重復校驗、冪等校驗（冪等控制）、資料唯一性校驗（資料防重控制），
你可以不“重復”做這些校驗，而simply依靠請求鏈路里的only一個節點的校驗來cover，在這種情況下，你的系統沒出現問題，只能說明你比較幸運，一直沒出現問題，說明你一直比較幸運，
最近我們系統是出現了這樣的事故，一個中臺dubbo服務提供了資料的新增介面，供下游業務線呼叫，系統運行了大半年也沒出現問題，而最近卻翻車了，一個業務線在特定的分支邏輯里缺乏有效的防重控制，致使在業務高峰期不停地重復刷這個介面（傳遞同樣的資料），而這個dubbo介面里沒有做業務防重，瞬時的高頻呼叫，不僅讓dubbo服務出現故障，還造成了大量的重復資料，隨之而來的是運營的催促，客戶的投訴，我們在處理重復資料時，耗費了大量的人力和時間成本，這一張多米諾骨牌，讓我們付出了慘痛的代價，
我是因為遇到了這么一個事故才寫這個blog嗎？
不是！許多大的事故往往就是類似小疏忽導致的，我遇到的這樣的事故簡直太多了，
你沒有遇到這樣的事故嗎？
我不信！
So，苦口婆心一番，愿小伙伴們別再為這樣的疏忽而翻車，
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請注明原文鏈接：https://www.cnblogs.com/buguge/p/16526829.html
<style>hr.signhr{width:80%;margin:0 auto;border: 0;height: 4px;background-image: linear-gradient(to right, rgba(0, 0, 0, 0), rgba(0, 0, 0, 0.75), rgba(0, 0, 0, 0))}</style>
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/500494.html
標籤：Java