为什么不应该重写service方法？

正文

请到「今天看啥」查看全文

浏览器也很聪明，当你再次（点击链接，或者F5，或者回车，但是不能是ctrl+F5）请求这个资源时，浏览器会询问server这个资源自上次告诉我的最后修改时间以来有没有被修改（请求头中If-Modified-Since）。（见图二）

如果资源没有被修改，server返回304状态码，并不会再次将资源发送给浏览器，浏览器则很知趣的使用本地的缓存文件。（见图二）

所以所有的静态资源如果没有发生变化，通常是不会传递多次的，不管什么浏览器或者server都应该遵守这种询问的约定。看起来很爽啊，很智能是不是？这种约定的机制就是 http缓存协商——这是约定优于配置的又一体现。

有了缓存协商的知识，理解为什么我们不应该重写service就很容易了。还是从代码出发，这次我们看一个复杂一点的例子。

在这个例子中，我们请求一个控制器（MeServlet），然后转向一个视图（index.html），为了简单起见，web.xml中将只有这个servlet的配置：

< web-app >
< servlet >
< servlet-name > me servlet-name >
< servlet-class > com.me.web.MeServlet servlet-class >
servlet >
< servlet-mapping >
< servlet-name > me servlet-name >
< url-pattern > /test url-pattern >
servlet-mapping >
web-app >


然后是MeServlet：

public class MeServlet extends HttpServlet {
@Override
protected void service (HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
/**
* 1. 处理具体的业务：
* -- 处理请求参数
* -- 检查缓存
* -- 处理具体数据
* -- 更新缓存
*/
doBizLogic(req, res);
/**
* 2. 根据处理的结果转向具体的视图：
* -- 这里假设就是 index.html
*/
getServletContext()
.getRequestDispatcher( "/index.html"

请到「今天看啥」查看全文