谁要是再敢用Map传参,我过去就是一JIO

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 谁要是再敢用Map传参,我过去就是一JIO

  点击上方 **好好学java **,选择 **星标 **公众号


重磅资讯、干货,第一时间送达
今日推荐:你这代码写得真丑,满屏的try-catch,全局异常处理不会吗?个人原创+1博客:点击前往,查看更多

还记得上次我写过一篇关于实际项目代码分层和规划的文章《》, 在文尾处提到过一些注意事项,其中第一条就是:

  • Contorller层参数传递建议不要使用HashMap,推荐使用数据模型定义
    私信里竟然有很多小伙伴提问说,为什么不能这样做?

我心里暗自寻思:难道这么做的小伙伴都没有被同事捶吗?(滑稽)

得嘞,今天咱们就掰扯掰扯这件事,这是实际写代码时常忽略的一个问题

是不是有人也这么写过?

我自己曾经接手过一个前人留下来的老项目,拿到代码,导入IDEA的那一刻,我哭出了声。

因为它的 Controller层代码都是类似这样写的:

附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南,这是本人这几年及春招的总结,目前,已经拿到了大厂offer,拿去不谢!

下载方式

1. 首先扫描下方二维码

2. 后台回复「Java面试」即可获取


@RestController
@RequestMapping("/index")
public class IndexController {

    // 获取App首页内容
    @PostMapping("/getIndexContent")
    public ResponseWrapper getIndexContent( @RequestBody Map<String, Object> paramMap ) {

        ResponseWrapper res = new ResponseWrapper();

        // 下面开始做传参有效性的校验
        if (!paramMap.containsKey("article_id")) {
            res.setCode(500);
            res.setMsg("缺少 article_id 信息");
            return res;
        }

        if (!paramMap.containsKey("page")) {
            res.setCode(500);
            res.setMsg("缺少 page 信息");
            return res;
        }

        if (!paramMap.containsKey("size")) {
            res.setCode(500);
            res.setMsg("缺少 size 信息");
            return res;
        }

        if (!paramMap.containsKey("version")) {
            res.setCode(500);
            res.setMsg("缺少 version 信息");
            return res;
        }

        // ...... 此处省略

    }

    // ...... 此处省略

}

别的咱先不说,居然明目张胆地在 Controller层里方法里用 Map传参?!简直丧心病狂了。幸亏下面还有一波传参有效性的验证,对于传递的参数,我好歹也能猜个大概,不然那真是喵了个咪了。

接下来,我们就好好唠一唠:为什么不要在 Controller层传参时使用 Map类型!

Map一时爽,维护爽歪歪

正好,这地方有一个咱小伙伴活生生的例子。

前段时间,有个小伙伴跟我提问交流,说他接手了一个别人的老项目,问了我一个类似这样的问题:

看到没!

Map传参的第一个(也是最大的一个)弊端就是:这会导致后续接手和维护的人怀疑自己的人生,因为他根本不知道代码传的啥参数,想要构造参数去调试接口只能靠脑补摸瞎、以及猜测了。

试想一下,其实我们代码里任何一个地方的传参都可以使用 Map来传,如果真的这么做了,代码中连任何数据模型类都不需要定义了,果真如此的话,这样的代码咱能看懂吗?

而且这位小伙伴接手的项目居然还用的是 LinkedHashMap参数,可以说很秀了。

除此之外,紧接着还会带来下面这个问题。

好用的API工具与你无缘了

我之前写过一篇文章《》,聊过现在市面上一些比较好用的、能极大提升前后端开发效率的API管理工具,这对于前后端开发来说,简直是莫大的福音。

我们就以 Swagger这个API工具为例,如果 Controller传参使用 Map的话:


// 获取App首页内容
@ApiOperation("获取App首页内容")
@PostMapping("/getIndexContent")
public ResponseWrapper getIndexContent( @RequestBody Map<String, Object> paramMap ) {

    // ...... 此处省略

}

API工具无法读取具体参数项目和参数类型,所以传参什么的也看不出来:

换言之,我如果将上面的 Map传参改为自定义数据模型类 IndexQueryDto来传参的话:


// 获取App首页内容
@ApiOperation("获取App首页内容(改造后)")
@PostMapping("/getIndexContent")
public ResponseWrapper getIndexContent( @RequestBody IndexQueryDto indexQueryDto ) {

    // ...... 此处省略

}

@ApiModel(value = "App首页内容请求参数实体对象")
class IndexQueryDto {

    @ApiModelProperty(value = "文章ID号")
    @NotNull(message = "缺少 article_id 信息")
    private Long article_id;


    @ApiModelProperty(value = "页面数")
    @NotNull(message = "缺少 page 信息")
    private Integer page;

    @ApiModelProperty(value = "每页条目数")
    @NotNull(message = "缺少 size 信息")
    private Integer size;

    @ApiModelProperty(value = "App版本号")
    @NotNull(message = "缺少 version 信息")
    private String version;

    // ...... 此处省略set/get方法

}

则类似 Swagger这种 API工具就非常方便地能帮助我们管理参数了:

这样不管是自己调试,还是前、后端对接口都会方便得多。

同理,除了 Swagger这种 API管理工具之外,像在我的前文《》中推荐过的一个非常好用的接口管理插件 RestfulToolkit也无法识别出 Map类型所盛放的具体参数:

但是对于数据模型的定义参数,就能非常清晰的给出参数细节,并方便地提供接口测试:

优秀的注解没法使用了

还是以文章开头举例的代码来说,不管怎么样,写这段代码的哥们还是负责的,毕竟兢兢业业地用手工连环 if()判断完成了所有参数的有效性校验:

但问题是,我们真的需要这种辣眼睛的手工连环 if()判断来做参数校验吗?

同样在前文《》中也说过了,我们其实可以通过注解来方便地规避繁杂的参数校验工作,但前提是不能使用 Map类型传参,需要使用数据模型的定义,就像这样:


class IndexQueryDto {

    @NotNull(message = "缺少 article_id 信息")
    private Long article_id;

    @NotNull(message = "缺少 page 信息")
    private Integer page;

    @NotNull(message = "缺少 size 信息")
    private Integer size;

    @NotNull(message = "缺少 version 信息")
    private String version;

    // ...... 此处省略get/set方法
}

一个 NotNull注解即可搞定,它不香吗?

Map传参真的一无是处吗?

有些小伙伴表示用 Map传参的好处就是可以随意扩展,后期变动灵活,想往里面塞几个参数就塞几个参数;而且也省去了各种对象定义和命名的烦恼。

如果非要用Map传参

如果实在不能避免用 Map传参,也麻请配备完备的测试用例吧,省得让后来接手维护的人天天看着代码怀疑人生了。

通过测试用例,后来接手维护的人也能快速搞清代码间的参数传递和调用,不然真的只能靠脑补画面去调试了。

嘘…

好了,说了这么多,如果你项目的`Controller层代码还在使用HashMap传参的话,答应我,二话别说,赶快全部偷偷去改掉,快!速度!跑步前进!

每天进步一点点,Peace!


最后,再附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南,这是本人这几年及春招的总结,目前,已经拿到了大厂offer,拿去不谢!下载方式1. 首先扫描下方二维码2. 后台回复「Java面试」即可获取

原文地址:https://sihai.blog.csdn.net/article/details/109465564

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 谁要是再敢用Map传参,我过去就是一JIO


 上一篇
我在实际工作中用的最多的 git 命令,全在这里了,使用简单! 我在实际工作中用的最多的 git 命令,全在这里了,使用简单!
点个赞,看一看,好习惯!本文 GitHub 已收录,这是我花了 3 个月总结的一线大厂 Java 面试总结,本人已拿大厂 offer。 另外,原创文章首发在我的个人博客:,欢迎访问。 前言最近在工作中频繁用到git版本管理,期间也
2021-04-04
下一篇 
【xmind】 使用 Java 生成思维导图 【xmind】 使用 Java 生成思维导图
  点击上方 **好好学java **,选择 **星标 **公众号 重磅资讯、干货,第一时间送达 今日推荐:你这代码写得真丑,满屏的try-catch,全局异常处理不会吗?个人原创+1博客:点击前往,查看更多 前言在日常的工作与学习中,
2021-04-04