需要捕获每一个请求的做特定处理。前段时间已经用 Filter 实现了一版,理论上 Spring 的 Interceptor 也可以实现,TODO抽空再试一版 Interceptor。
先列举一下两者区别:
Filter | Interceptor | Summary |
---|---|---|
Filter基于函数回调 | Interceptor 基于java的反射机制 | |
Filter 接口定义在 javax.servlet 包中 | 接口 HandlerInterceptor 定义在org.springframework.web.servlet 包中 | |
Filter 定义在 web.xml 中 | ||
Filter 只能在容器初始化时被调用一次 | 在 action 的生命周期中,Interceptor 可以多次被调用 | |
Filter在只在 Servlet 前后起作用。Filters 通常将 请求和响应(request/response) 当做黑盒子,Filter 通常不考虑servlet 的实现。 | 拦截器能够深入到方法前后、异常抛出前后等,因此拦截器的使用具有更大的弹性。允许用户介入(hook into)请求的生命周期,在请求过程中获取信息,Interceptor 通常和请求更加耦合。 | 在Spring构架的程序中,要优先使用拦截器。几乎所有 Filter 能够做的事情, interceptor 都能够轻松的实现 |
Filter 是 Servlet 规范规定的。 | 而拦截器既可以用于Web程序,也可以用于Application、Swing程序中。 | 使用范围不同 |
Filter 是在 Servlet 规范中定义的,是 Servlet 容器支持的。 | 而拦截器是在 Spring容器内的,是Spring框架支持的。 | 规范不同 |
Filter 不能够使用 Spring 容器资源 | 拦截器是一个Spring的组件,归Spring管理,配置在Spring文件中,因此能使用Spring里的任何资源、对象,例如 Service对象、数据源、事务管理等,通过IoC注入到拦截器即可 | Spring 中使用 interceptor 更容易 |
Filter 是被 Server(like Tomcat) 调用 | Interceptor 是被 Spring 调用 | 因此 Filter 总是优先于 Interceptor 执行 |
Filter 不能获取IOC容器中的各个bean | Interceptor 可以获取IOC容器中的各个bean | 这点很重要,在拦截器里注入一个service,可以调用业务逻辑 |
再借一张网图: