关于《对 Action 的初步构思》的阅读思考

看了一篇文章对 Action 的初步构思。

作者对方案二的解读自己也很有体会，很有共鸣。

@Request(url = "/product", method = "GET")
public Result getProductById(HttpServletRequest request) {
    long productId = Integer.parseLong(request.getParameter("id"));
    if (productId == 0) {
        return new Result(ResultError.ERROR_PARAM_INVALID);
    }
    Product product = productService.getProduct(productId);
    if (product != null) {
        return new Result(ResultError.OK, product);
    } else {
        return new Result(ResultError.ERROR_DATA_NULL);
    }
}

作者解读道：

此方案实现起来最为简单，但需要与 Servlet API 依赖，所有的参数必须通过 Request 对象获取，而且不支持 REST 风格的 URL（只能是 /product?id=1 这样的）。此外，单元测试也比较痛苦，需要 mock 出 Request 对象。

这种从HttpServletRequest中获取参数的方式和直接的参数映射方式的区别自己没有仔细考虑过，但确实在使用的时候遇到过，当时只是想着HttpServletRequest很麻烦，具体的麻烦的地方没有仔细的表达出来。现在看到作者的这段话，就是我脑海中的"麻烦"。为了更清晰的阅读，我换一种排版如下：

1、依赖Servlet API

2、不支持REST风格URL

3、单元测试痛苦

当然，为什么这么"麻烦"有的时候还用呢？换句话说，HttpServletRequest中获取参数和SpringMVC的参数映射的区别是什么？（设计思想、使用习惯、各自有缺点）

 

首先明确一点，不管使用上面哪种方式获取参数，参数的原始形式是二进制流，两种都是框架对流的包装。

当初使用SpringMVC的时候还使用HttpServletRequest，应该是因为直接通过SpringMVC的参数映射获取不到参数，应该是对SpringMVC使用细节并不清楚，所以使用了相对原始的HttpServletRequest。所以接下来需要安排时间学习一下SpringMVC源码，弄懂内部原理，比如如何封装请求的参数的。

未完。。。待续。。。

 

思维真的是花火，如果有些想法、感受，不写下来分析分析，就稍纵即逝，也就不重视，久而久之，错过的越多，当下就会过的越无趣。

参考：

1、springmvc的参数接收不能兼容以及HttpServletRequest中的流多次使用

2、SpringtMVC运行流程：@RequestMapping 方法中的 Map、HttpServletRequest等参数信息是如何封装和传递的（源码理解）