在学生管理系统里，其中会有学生信息采集的功能。程序结构不外乎下面的分层实现方式。
开发出来这个功能，我觉得大家都易如反掌了。
当然易如反掌。
OK，我要说的是数据校验，以最简单的非空校验（例如：学生姓名不可为空）来说：
首先，前端页面的表单要校验，为空则不允许提交，非空则调用后端api接口来post数据。
其次，后端程序的controller里要校验，为空则直接返回错误提示，非空则调用StudentService类。
再次，StudentService类要校验，为空则直接返回错误提示，非空则在其他校验通过后，进行数据的持久化。
上面的“再次”，在单体应用内不做校验也可————而一旦是在RPC调用的情况下，是必须要做的。
那么，聪明的你，有没有，或者曾经有没有，忽视上面的几处校验呢？
你也许会说No. ————肯定会做校验呀。
你也许还会说but why？————为什么要这么多处校验呢？一个地儿校验住不就完了吗？
First，为什么前端要校验？
--> 前端页面校验不通过时，则直接在页面提示给用户了，好处：①响应快，因为无须调用后端api，也减少了网络通信；②用户体验会好一些。
Second，前端已经校验了，为什么后端还要校验？
--> 正常情况下是不需要后端再校验了。非正常情况下呢？例如，前端没拦住，再例如，请求不是前端发过来的...
Third，为什么service类还要校验？
--> 上面说了，如果是单体应用，你不校验也行。而如果是局域网RPC服务之间调用的话，你还真要加上这个校验。也是为了防止非正常情况的。
多次一举？
实际企业应用开发中，类似的需要多处“重复”做的校验包括：数据合法性校验、数据重复校验、幂等校验（幂等控制）、数据唯一性校验（数据防重控制）。
你可以不“重复”做这些校验，而simply依靠请求链路里的only一个节点的校验来cover。在这种情况下，你的系统没出现问题，只能说明你比较幸运。一直没出现问题，说明你一直比较幸运。
最近我们系统是出现了这样的事故。一个中台dubbo服务提供了数据的新增接口，供下游业务线调用。系统运行了大半年也没出现问题，而最近却翻车了。一个业务线在特定的分支逻辑里缺乏有效的防重控制，致使在业务高峰期不停地重复刷这个接口（传递同样的数据），而这个dubbo接口里没有做业务防重。瞬时的高频调用，不仅让dubbo服务出现故障，还造成了大量的重复数据。随之而来的是运营的催促，客户的投诉，我们在处理重复数据时，耗费了大量的人力和时间成本。这一张多米诺骨牌，让我们付出了惨痛的代价。
我是因为遇到了这么一个事故才写这个blog吗？
不是！许多大的事故往往就是类似小疏忽导致的。我遇到的这样的事故简直太多了。
你没有遇到这样的事故吗？
我不信！
So，苦口婆心一番，愿小伙伴们别再为这样的疏忽而翻车。
标签：非空,调用,重复,前端,校验,80%,程序员,数据 来源： https://www.cnblogs.com/buguge/p/16526829.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。