SpringBoot系列之从0到1实现自定义web参数映射器
在使用SpringMVC进行开发时，接收请求参数属于基本功，当我们希望将传参与项目中的对象关联起来时，最常见的做法是默认的case（即传参name与我们定义的name保持一致），当存在不一致，需要手动指定时，通常是借助注解@RequestParam来实现，但是不知道各位小伙伴是否有发现，它的使用是有缺陷的
@RequestParam不支持配置在类的属性上
如果我们定义一个VO对象来接收传承，这个注解用不了,如当我们定义一个Java bean(pojo)来接收参数时，若是get请求，post表单请求时，这个时候要求传参name与pojo的属性名完全匹配，如果我们有别名的需求场景，怎么整？
最简单的如传参为: user_id=110&user_name=一灰灰
而接收参数的POJO为
public class ViewDo {
private String uesrId;
private String userName;
}
2
3
4
SpringBoot系列之Web如何支持下划线驼峰互转的传参与返回
接下来介绍一个非常现实的应用场景，有些时候后端接口对外定义的传参/返回都是下划线命名风格，但是Java本身是推荐驼峰命名方式的，那么必然就存在一个传参下换线，转换成驼峰的场景；以及在返回时，将驼峰命名的转换成下划线
那么如何支持上面这种应用场景呢?
本文介绍几种常见的手段
在日常的业务需求开发过程中，批量插入属于非常常见的case，在mybatis的写法中，一般有下面三种使用姿势
- 单个插入，业务代码中for循环调用
<foreach>标签来拼接批量插入sql- 复用会话，拆分小批量插入方式
在使用mybatis进行数据库操作时，如果希望将返回结果映射为项目中定义的实体对象Entity时，ResultMap与ResultType就很重要了；它们两的主要区别在于ResultType指定指定实体对象，ResultMap则定义数据库字段与实体的映射关系
接下来通过简单的实例来看一下这两种的使用姿势
借助Grafana来实现大盘配置，关于Grafana的启用配置，这里就不详细说明，有兴趣的可以查看前文 * 【中间件】Prometheus实现应用监控 | 一灰灰Blog
接下来主要是针对上一篇 【中间件】Prometheus基于AOP实现埋点采集上报
关于Prometheus的自定义埋点，前一篇博文已经介绍了，为啥这里又来一次？
看过前文的小伙伴可能会知道，之前采用的simpleclient包定义的几个metric来实现的，实际上有更简单方便的姿势，那就是直接借助MeterRegistry来创建Metric来实现数据采集即可
相比较于前文的实现，总的来说简易程度可见一般，上篇文章可以点击下文查看
在实际的业务开发中，为了方便获取Spring容器中的Bean对象，一个常见的case就是创建一个SpringUtil类，内部持有SpringContext上下文，然后提供一个静态的方式获取bean对象，然而这种使用姿势，一个不小心可能导致npe
今天我们来看一下这个场景
之前介绍过一篇拦截器的基本使用姿势: 【WEB系列】SpringBoot之拦截器Interceptor使用姿势介绍
在SpringBoot中，通过实现WebMvcConfigurer的addInterceptors方法来注册拦截器，那么当我们的拦截器中希望使用Bean时，可以怎么整？
话说自从前后端分离之后，前后端放在一起的场景就很少了，最近写个简单的后台，突然踩坑了，使用themeleaf模板渲染时，发现th:each来遍历生成表单数据，一直抛异常，提示Property or field 'xxx' cannot be found on null
接下来看一下这个问题到底是个什么情况