本篇文章为你整理了就这么一个简单的校验，80%的程序员却做不到，更不理解！（校验的方法）的详细内容，包含有校验程序是什么 校验的方法 校验和怎么计算举个例子 校验是干嘛的 就这么一个简单的校验，80%的程序员却做不到，更不理解！，希望能帮助你了解 就这么一个简单的校验，80%的程序员却做不到，更不理解！。

　　在学生管理系统里，其中会有学生信息采集的功能。程序结构不外乎下面的分层实现方式。

　　开发出来这个功能，我觉得大家都易如反掌了。

　　当然易如反掌。

　　OK，我要说的是数据校验，以最简单的非空校验（例如：学生姓名不可为空）来说：

　　首先，前端页面的表单要校验，为空则不允许提交，非空则调用后端api接口来post数据。

　　其次，后端程序的controller里要校验，为空则直接返回错误提示，非空则调用StudentService类。

　　再次，StudentService类要校验，为空则直接返回错误提示，非空则在其他校验通过后，进行数据的持久化。

　　上面的“再次”，在单体应用内不做校验也可————而一旦是在RPC调用的情况下，是必须要做的。

　　那么，聪明的你，有没有，或者曾经有没有，忽视上面的几处校验呢？

　　你也许会说 No, of course not. ————肯定会做校验呀。

　　你也许还会说 Butwhy？————为什么要这么多处校验呢？一个地儿校验住不就完了吗？

　　First，为什么前端要校验？

　　-- 前端页面校验不通过时，则直接在页面提示给用户了，好处：①响应快，因为无须调用后端api，也减少了网络通信；②用户体验会好一些。

　　Second，前端已经校验了，为什么后端还要校验？

　　-- 正常情况下是不需要后端再校验了。非正常情况下呢？例如，前端没拦住，再例如，请求不是前端发过来的...

　　Third，为什么service类还要校验？

　　-- 上面说了，如果是单体应用，你不校验也行。而如果是局域网RPC服务之间调用的话，你还真要加上这个校验。也是为了防止非正常情况的。

　　在实际企业应用开发中，因为非正常情况的概率性事件存在，所以，我们需要“重复地”来做这些校验。类似的需要多处“重复”做的校验包括：数据合法性校验、数据重复校验、幂等校验（幂等控制）、数据唯一性校验（数据防重控制）。

　　你也许会继续追问：哪有那么多非正常情况呀？？？？

　　你可以不“重复”做这些校验，而simply依靠请求链路里的only一个节点的校验来cover。那么，你这种“半裸奔”的系统没出现问题，只能说明你比较幸运。一直没出现问题，说明你一直比较幸运。

　　最近我们系统碰巧又出现了这样的事故。一个中台dubbo服务提供了数据的新增接口，供下游业务线调用。系统运行了大半年也没出现问题，而最近却翻车了。一个业务线在特定的分支逻辑里缺乏有效的防重控制，致使在业务高峰期不停地重复刷这个接口（传递同样的数据），而这个dubbo接口里没有做业务防重。瞬时的高频调用，不仅让dubbo服务出现故障，还造成了大量的重复数据。随之而来的是运营的催促，客户的投诉，我们在处理重复数据时，耗费了大量的人力和时间成本。这一张多米诺骨牌，让我们付出了惨痛的代价。

　　我是因为遇到了这么一个事故才写这个blog吗？

　　不是！许多大的事故往往就是类似小疏忽导致的。我遇到的这样的事故简直太多了。

　　你没有遇到这样的事故吗？

　　我不信！So，一番碎碎念，愿小伙伴们别再为这样的疏忽而翻车。

　　
当看到一些不好的代码时，会发现我还算优秀；当看到优秀的代码时，也才意识到持续学习的重要！--buguge
本文来自，转载请注明原文链接：https:///buguge/p/16526829.html

　　以上就是就这么一个简单的校验，80%的程序员却做不到，更不理解！（校验的方法）的详细内容，想要了解更多 就这么一个简单的校验，80%的程序员却做不到，更不理解！的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。