spring MVC中接口参数解析的过程详解
前言
前天工作中遇到了这样一个问题,我在接口的参数封装了一个pojo,这是很常见的,当参数一多,惯性的思维就是封装一个pojo.那么在参数前有很多注解可以添加,比如:@requestParam,@requestBody,@pathvariable等。我的理解是这样的,首先我先申明,我并是没有看过源码,只是凭经验理解。@requestParam试用于get请求,参数在http的header中的URL上,具体放在?后面以key=value的形式存在。@requestBody适用于post请求中参数在http的body中。@pathvariable比较特别是restful的写法,把参数放在URL上,不用问号区分是参数还是URL。也许我这样说不是很准确。但我通常也是这么用的。与此同时,还有一种常见的写法,就是参数前不加注解,比如参数是基本类型的不加@requestParam,参数是bean的不加requestBody,也能被springmvc解析得到。我的接口被小组长看到之后他叫我去掉这个@requestBody,因为后端加上这个之后,前端的ajax请求需要显示的声明content-type:"application/json",才能被springmvc解析得到,这样似乎多做了一件不必要的事情。虽然我按照他的要求去掉了,但是我觉得我得弄清楚这到底是怎么回事,加与不加到底有什么区别,对性能有什么影响,或者各自的最佳适用场景,除了百度,还得问问大神。
spring MVC接口参数解析的过程
首先我自己慢慢的通过debug研究了一下源码。在不添加任何注解的情况下:
在开发的过程中consumes和produces一般都没有加,按道理应该要加上,因为可以减少对接口的查找范围。这是一个简单的demo,我只是需要他来检查springmvc接收请求的流程。
首先在tomcat启动之后,所有controller类中的请求路径也就是@requestMapping随着Controller这个bean加载到了spring的容器中。页面请求过来之后找到DispatcherServlet这个servlet,请求走到servlet之后大家都知道servlet有两种初始化方式,一种是随着立即加载,一种是延迟加载,但是无论怎样,都是只调用一次init方法,然后再以后每次都会直接调用service方法,当tomcat关闭之后servlet的destroy方法被调用生命周期就结束了。所以springmvc是对servlet的封装就必定要继承service方法,DispatcherServlet也就是doDispatch这个方法。这个方法中通过HttpServletRequest对象获得请求路径也就是/notJson,然后与容器中的所有url对比,最终取得Controller中的接口所在。找到了接口自然就知道了接口的参数,我这里就是Display,为了方便简单,Display中只有两个参数,就是下面ajax请求中的两个。
springmvc会通过反射的方式获取到pojo中的属性。在这个过程中首先springmvc会先声明一个数组,这个数组的大小是参数的个数,我这里只有一个,其实我相信很多人会和我遇到相同的问题就是,当参数中同时存在bean和基本类型的参数,springmvc将怎么解析,这个我遇到过几次,在没有看源码的情况下,把基本类型也封装到bean中去了,让前端把属性也写在一个对象中。当然我相信这个不是每个人都能接受的做法,我们都希望搞清楚他究竟是怎样解析的,到时候我们就可以任意摆弄了。下面是反射过程,将我的pojo反射之后获得里面的属性和方法。解析了参数之后,为参数赋值。这里也许是最重要的地方了。究竟是怎么赋值的。
从这个方法debug了解到,name为display,也就是pojo类名的小写,这里不知道为什么springmvc做了这个处理(以后再看)。attribute为带有age和name的对象。不过此时都是null。WebDataBinding用于从Web请求参数到JavaBean对象的数据绑定的特殊DataBinder。接上图bindRequestParameters这个方法,跟进去会发现一个很熟悉的地方就是下图,通过String[] values = request.getParameterValues(paramName);
获得参数名,这个是servlet的获取参数方法,那么就可以知道请求的参数的属性名和属性值。
接下来可想而知就是把这个参数名name换成bean的属性name,参数名age换成属性名age。再跟到这个地方,这个oragina就是上面serclet拿到的属性名值对,把这个map在这转化成PropertyValue。(PropertyValue是用于保存单个bean属性的信息和值的对象。 在此处使用对象,而不是仅将所有属性存储在由属性名称键入的映射中,允许更灵活,并且能够以优化的方式处理索引属性等。请注意,该值不需要是最终所需的类型:BeanWrapper实现应该处理任何必要的转换,因为此对象不知道它将应用于哪些对象。),如此一来就有两个PropertyValue对象了。
转化的时候会忽略不知道的属性
上图是具体转化的方法,方法比较长。下面一句直接给bean赋值。从这个过程来看。只要前端的json对象的属性和后端的bean属性一样,ajax不写content-type,用默认的application/x-www-form-urlencoded; charset=UTF-8
,就能直接赋值。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。