Spring controller 的两个问题

@JsonProperty

用 Vo ，接收参数不行么=。=，VO=》 Pojo

Map 的话尝试下 HashMap

@taofoo Map 确实是一个借口

@chihiro2014 VO 和 POJO 是一个层面的定义吗？ Value Object 不是 POJO 吗

先用一个 request 来接 http 进来的参数，然后用一个 mapper 把 request 转到 domian 里面的 entity 就好了。

1. 如果是 json 的话就一楼的注解，否则的话建议直接写一个新类专门做这个参数接收，然后再转换过去
2. 实测 RequestBody 的话可以用 Map 接

3. 严重不建议使用 Map 接收参数，严重不建议接 HttpServleetRequest 再自己解析参数

@chendy
为什么不建议自己解析参数呢？

后端如果全部用 RequestBody 会很痛苦 一两个参数都得定义一个 Bean
一会用 RequestBody 一会用 RequestParam
前端又会 BB

自己解析就很自由了
前端都用 post json
重写 request 自己解析到参数
想用 RequestParam 接也行 用 RequestBody 接也行

不建议使用 Map 接收参数
1.key 要写死到 controller 里
2.如果对参数有校验还要逐层解析
3.如果入参结构复杂，controller 里一片解析，而且后边维护成本较高

如果只是变量名不一致，一楼正解。七楼说的有道理，建议建一个新类去接收参数。在加上 @Valid 做入参校验
(@Valid @RequestBody 新类 VO vo)

如果担心会出现一大堆入参 bean ，记得把参数名字尽量搞的能公用些。
退一步说，总不会所有的请求都是 POST 吧

@heliotrope
我们一般多余 3 个参数会定义 Bean

自己解析有额外的样板代码，而且还得做数据校验，用 Bean ，简单校验都走 Spring Validation 了

按照 RESTful 的一般定义来说，请求方法是和 controller 的功能相关的，再不济只区分 get 和 post 也行，前端全都用 post json 未免也太粗暴了。不用 map 或者自己解析参数最大的原因是，通过 bean 或者 controller 的形参直接就能知道 controller 需要什么参数，而不是出现变动之后还得去看内部实现逻辑。这样对维护很友好，而且 map 也比 bean 重很多

话说 axios 之类的库都把这些操作封装的很好了，query 也可以传一个 object 进去，让 axios 自己转成 url 参数，这前端还觉得烦是不是有点怪（

现在 post 请求带的数据应该都在 body 里了吧，所以都是用 @requestbody 来接收参数。一般我是在三方接口回调的时候会用 map 或者 jsonobject 来接收参数，除此之外，都是定义一个 model 来接收比较多。requestparam 一般也用的少，直接就在方法的入参列表写参数名就好了，除非请求上的入参名称和方法的参数名称不一样才会用 requestparam ，或者是设置默认值的情况。

参数的 key 和变量名不同就新建 VO 呗 更何况 POJO 和 VO 不是一码事

@Vegetable 不是。VO= View Project ，视图层用。DTO 传输数据用，PO 相当于 Entity 了。细分还有 BO 啥的。。看具体咋用。主要作用还是区分作用域，方便日后代码重构

@chihiro2014 POJO 对应的实际上时 Bean 吧，根本就和 VOPODTO 不是一层的概念

不建议自己使用 request 对象来解析参数，还有个理由是为了保持方法的一个简单（和 request 对象解耦），和普通方法没什么区别。写单元测试也简单

form 或者 query 转 po