成为VIP
SpringBoot + Mybatis + Shiro + mysql + redis智能平台源码分享 推荐阅读
1 抛砖引玉
先来看一段十分基础的业务代码
Map map = service.getDataByName("悟空GoKu");
Long userId = (Long)map.get("userId");
String phone = (String)map.get("phone");
复制代码每次我写这种map获取返回数据总是感觉十分别扭
map就像个无底洞，你不看服务提供方代码的话就不知道里面到底放了什么key。拿到数据之后都要自己强转一下，有点麻烦。这玩意有潜在的类型转换异常发生。2 请求参数Request
首先要肯定的是用map来传输参数（前端http请求后端接口）真的是方便，不需要额外去定义一个类，想往里面塞什么数据就塞什么，就如下面的例子，不需要为每个接口都定义一个RequestVo类，统一map接收
@PostMapping(value = "/map")
public ApiResponse testMap(@RequestBody Map map) {
//获取map中的数据
Long userId = (Long)map.get("userId");
String phone = (String)map.get("phone");
//业务代码...
return ApiResponse.ok();
}
复制代码上面说了我不喜欢这样获取数据，但也不喜欢定义一个类来接收，因为这样会造成类数量激增，可能一个请求接口就得对应创建一个请求类。
有人说不定义成类，有些额外的功能就无法使用：
swagger这种文档注解无法完美兼容。
不想用swagger，代码侵入性太强，样式、目录展示也一般，接口文档推荐开源yapi
swagger有时确实方便，增加参数时，代码跟文档同时更新，不必额外维护文档，但我还是不喜欢将文档跟代码耦合在一起。
validator验证注解无法使用。
验证逻辑我还是喜欢写在controller，逻辑更清晰。
原来的注解不一定适合某些复杂验证，那岂不是要自定义注解，又回到了类激增的问题
说回了map，map.get（key）这样获取数据确实别扭，但我们可以封装请求啊， 例如上一篇文章提到的ApiRequest。
public class ApiRequest implements Serializable {
//....省略部分代码
private Map data; //通过拦截器处理后请求参数已存放在这里
public Long getDataParamAsLong(String name, Long defaultValue) {
Long i = defaultValue;
try{
i = StringUtils.isNotEmpty(getDataParamAsString(name)) ?
Long.valueOf(getDataParamAsString(name)) : defaultValue;
}catch (Exception e){
e.printStackTrace();
}
return i;
}
}
复制代码@PostMapping(value = "/test")
public ApiResponse test(ApiRequest apiRequest) {
Long userId = apiRequest.getDataParamAsLong("userId", 0L);
//省略部分代码....
ApiResponse response = ApiResponse.ok()
return response;
}
复制代码这里已经是面向json编程了，而不是以往的面向对象。
3 响应参数Response
对于返回数据，我一般会在controller层拿到service的数据后再根据业务需求来处理数据（结构修改json转map，数据整合），最终用map整合再response，给前端一个合适的结构， 而不是数据库查到什么就整个类对象返回。
当前有些返回数据我也会定义一个类ReponseVo封装，最后return给前端
你这前后矛盾啊，之前还说不要面向对象。
这里主要考虑的有些场景下，多个接口返回的数据完全一样，可以共用。 对于部分app开发者来说，他们会依赖后台的接口来定义自己的model，相似的数据会要求后台返回的字段命名和结构一样，以便他们能共用model。
这…….其实他们可以自己定义属于他们的model，而不是完全依赖后台字段命名。
4 service层数据传输
前面说的是前端/移动端http请求我们的网关接口，这里是说我们服务端之间的远程方法调用/本地方法调用，也可以理解成service层方法调用。如果是多个参数的话，需要封装一个DTO，这里最好不用map。
这种接口我们不可能去写一份文档来维护。数据反序列化问题（划重点）。
如果某个方法内部使用了缓存json转map，且通过json反序列化后才返回，容易引发调用方发生异常
//set
@PostMapping(value = "/setData")
public ApiResponse setData(ApiRequest request) {
//省略部分代码...
Map map = new HashMap();
map.put("id", 123L);
map.put("name", "悟空GoKu");
stringRedisTemplate.set("KEY_GOKU", JsonUtil.toJsonString(map));
return ApiResponse.ok();
}
//get
@PostMapping(value = "/getData")
public ApiResponse getData(ApiRequest request) {
Map map = stringRedisTemplate.get("KEY_GOKU", Map.class);
Long id = (Long)map.get("id"); //会发生异常ClassCastException
return ApiResponse.ok();
}json 反序列化 map 时如果原来的整数值小于 int 最大值，反序列化后原本为 Long 类型的字段，会变为 Integer 类型。
json 序列化的优势在于可读性更强。但没有携带类型信息，只有提供了准确的类型信息才能准确地进行反序列化，这点也特别容易引发线上问题。
5 总结
最后来几句总结阐述下本文的观点，仅代表个人看法
前端/移动端请求接口，面向json编程，用map来传输数据，部分接口的返回数据可定义成VO类服务端之间的方法调用，多个参数的话需要定义DTO类来传输数据。前后端联调，有一份清晰可见的接口文档极为重要，写好代码的同时不要忘记也要写好文档。
特别想diss那些字段不写注释、代码加了字段又不同步到文档的后端开发者hhh
限时特惠：本站每日持续更新海量设计资源，一年会员只需29.9元，全站资源免费下载
站长微信：ziyuanshu688
htebazile
