教你做兼职的网站,百度搜索官方网站,品牌建设总结报告,新手做外贸哪个平台好这篇文章#xff0c;我们聊聊 Mybatis 动态 SQL #xff0c;以及我对于编程技巧的几点思考 #xff0c;希望对大家有所启发。 1 什么是 Mybatis 动态SQL
如果你使用过 JDBC 或其它类似的框架#xff0c;你应该能理解根据不同条件拼接 SQL 语句有多痛苦#xff0c;例如拼…这篇文章我们聊聊 Mybatis 动态 SQL 以及我对于编程技巧的几点思考 希望对大家有所启发。 1 什么是 Mybatis 动态SQL
如果你使用过 JDBC 或其它类似的框架你应该能理解根据不同条件拼接 SQL 语句有多痛苦例如拼接时要确保不能忘记添加必要的空格还要注意去掉列表最后一个列名的逗号。
Mybatis 借助功能强大 OGNL 表达式可以根据参数条件动态生成执行 SQL 。
使用动态 SQL 最常见情景是根据条件包含 where 子句的一部分。 这条语句提供了可选的查询博客文章列表 ,如果不传入 “title”那么所有处于 “ACTIVE” 状态的 博客都会返回。
如果传入了 “title” 参数那么就会对 “title” 一列进行模糊查找并返回对应的 BLOG 结果。
如果希望通过 “title” 和 “author” 两个参数都可以搜索只需要加入另一个条件即可见下图 我们也可以使用 where 标签该标签只会在子元素返回任何内容的情况下才插入 “WHERE” 子句。而且若子句的开头为 “AND” 或 “OR”where 标签也会将它们去除。 Mybatis 还支持 choose (when, otherwise)、trim (where, set)、foreach 等其他的动态标签这里就不一一赘述了。
2 人生第一次线上OOM事故
我曾服务一家电商公司的用户中心用户中心提供用户注册查询修改等基础功能 。
那个时候 Dubbo 等 RPC 框架并没有开源所有的服务都以 HTTP 接口形式提供数据传输格式是 XML 。
因为写接口非常费劲所以为了接口复用我写了一个通用接口 getUserByConditions 该接口支持通过 「用户名」、「昵称」、「手机号」、「用户编号」这三个查询用户基本信息。
使用的是 ibatis mybatis 的前身, SQLMap 见下图 。 当构建动态 SQL 查询时条件通常会追加到 WHERE 子句后而以 WHERE 1 1 开头可以轻松地使用 AND 追加其他条件。
用户中心在上线后竟然每隔三四个小时就发生了内存溢出问题 经过通过和 DBA 沟通发现高频次出现全表查用户表执行 SQL 变成 查看日志后发现前端传递的参数出现了空字符串笔者在代码中并没有做参数校验所以才出现全表查询 当时用户表的数据是 1000多万 页面调用几次用户中心服务就 OOM 了。
最终解决问题的方式很简单后端在接收参数时做了参数校验。
事故虽然解决了但对我的影响一直延续至今。我仍然记得当时站在运维同学旁边不断的看他调整 JVM 参数 重启服务的画面自己那个时候真的是羞愧难当心中发誓以后绝对不可以发生类似的事故。
对于动态 SQL 我的编程思维也经历了如下三个阶段 前后端参数校验 复用和专用要做平衡 防御性编程意识
3 前后端参数校验
为了提升开发效率我们人为的将系统分为前端、后端分别由两拨不同的人员开发 经常出现系统问题时两拨人都非常不服气相互指责。
要想系统健壮前后端应该同时做接口参数校验 后端必须做参数校验当大家都遵循这个规约时出现系统问题的风险大大减少。
1、前端校验 前端校验主要是为了提高用户体验例如用户输入一个邮箱地址要校验这个邮箱地址是否合法没有必要发送到服务端进行校验直接在前端用 js 进行校验即可。
但是大家需要明白的是前端校验无法代替后端校验前端校验可以有效的提高用户体验但是无法确保数据完整性因为在 B/S 架构中用户可以方便的拿到请求地址然后直接发送请求传递非法参数。
2、后端校验
后端必须做参数校验后端必须做参数校验后端必须做参数校验重要的事情表达三次。
数据在网络传输过程中有可能被篡改了或者数据不满足业务需求假如不做后端参数校验则有可能导致系统异常或者业务出现重大事故。
比如在 SpringBoot 项目中我们可以使用 hibernate-validator 进行参数校验 。
POST、PUT 请求一般会使用 requestBody 传递参数这种情况下后端使用 DTO 对象进行接收。
只要给 DTO 对象加上 Validated 注解就能实现自动参数校验。比如有一个保存 User 的接口要求 userName 长度是 2-10account 和 password 字段长度
是 6-20。
在 DTO 字段上声明约束注解 在方法参数上声明校验注解: 虽然我们可以使用接口校验可以保证动态 SQL 的参数正确但是假如我们仅仅只是复用 SQLMap Dao 方法时也有可能因为调用方传递参数错误导致非预期的问题。
当然我们也可以使用 Mybatis 拦截器从根本上来解决但是我想这样会加大系统的复杂度。于是我思考了了另外一点复用和专用要做平衡。
4 复用和专用要做平衡
我当时写的那个接口 getUserByConditions 是支持四种不同参数的查询同样也是为了省时间快点出活。
后来随着我工作经验的日益丰富我的编程习惯也慢慢发生了改变对于业务需求明确的场景我更多的倾向于将通用接口拆分成专用接口。
比如 getUserByConditions 可以拆分成如下四个接口 按照用户 ID 查询用户信息 按照用户昵称查询用户信息 按照手机号查询用户信息 按照用户名查询用户信息
比如按照用户 ID 查询用户信息 SQLMAP 就简化为 通过这样的拆分我们的接口设计更加细粒度也更容易维护 , 同时也可以规避 where 1 1 产生的不确定性虽然我做了后端校验依然存在不确定性。
有的同学会有疑问假如拆分得太细会不会增加我编写接口和 SQLMap 的工作量
笔者的思路是定制自己的代码生成器将生成的 SQLMap 、Mapper 保证更细的颗粒度。
5 防御性编程意识
笔者刚入行的时候只是机械性的完成任务并没有思考代码后面的资源占用以及有没有可能产生恶劣的影响。
随着见识更多的系统学习开源项目笔者慢慢培养了一种习惯 这段代码会占用多少系统资源 如何规避风险 做好预防性编程。
其实这和玩游戏差不多 在玩游戏的时我们经常说一个词那就是意识。 上图后裔跟墨子在压对面马可蔡文姬看到小地图中路铠跟小乔的视野方向是往下路来的这时候我们就得到了一个信息。
知道对面的人要来抓或者是协防这种情况我们只有两个人其他的队友都不在只能选择避战强打只会损失两名“大将”。
通过小地图的信息并且想出应对方法就是叫做“猜测意识”。
编程也是一样的我们思考代码可能产生的系统资源占用以及可能存在的风险并做好防御性编程就是编程的意识。
6 写到最后
人生第一次线上 OOM 事故因我在使用 Mybatis 动态 SQL 时没有做后端校验而出现造成了比较坏的影响。
在后面的职业生涯里面为了规避生产环境的事故我试着打磨自己的编程思维比如做好后端校验、平衡好复用和专用接口、培养防御性编程的意识 。
絮絮叨叨这么多大家可能觉得我小题大做了但事实是类似我这样的事故层出不穷上周我又目睹了一起。
IT 世界有了那么多框架好像我们依然写不好代码我有点沮丧。
