关于SpringMVC中的Interceptor


本次文章需要记录一个知识点,关于springMVC中的拦截器的使用,主要是因为在不断的学习过程中发现自己对于拦截器的使用和理解不是很到位,在此记录新的心得


1,springMVC中创建自己的拦截器的方式:建立自己的拦截器类实现接口:HandlerInterceptor,此时需要实现三个方法的实现(并不是必须实现),然后再在spring的配置文件中配置自己的拦截器,引用刚刚的类设置请求拦截的匹配方式

2,新的理解,一、结合自定义的注解实现对于某些特殊的用户请求,进行相应的处理,而不是过统一的拦截处理逻辑,这样绝对是好过从request中取出请求路径与事先约定进行比较从而进行对应处理有很大优势(简洁,而且易于管理,当某些请求不再需要进行特殊处理时仅仅需要将对应请求的注解去掉即可,而不是重新检查修改已经变的又臭又长的拦截器里面的处理逻辑);二、请求返回数据的校验;三、统一的异常处理


3,拦截器的基本概述,还是再简单的叙述一下拦截器的方法作用吧,实现HandlerInterceptor接口之后需要实现三个方法:preHandle,当servlet接受用户请求到达指定方法前调用,postHandle 当接受用户请求,经过对应的url处理,并且将数据渲染到ModelAndView之后调用,此时数据还没有返回到客户端,afterCompletion,当整个用户请求和服务处理操作全部完成后调用


在上面所提到的三个方法中有许多很重要的参数,利用好这些方法可以在我们的web系统开发中事半功倍!!


关于preHandle,这个方法应该是所有javaweb开发人员最熟识的一个方法,但是由于在日常工作中绝大多数的工作的中心都是在业务部分,而框架这部分基本都是停留在灰度认知,知道怎么回事,知道大概怎么用。所以当用到拦截器,提到这个方法基本能想到的就是一个操作登录拦截。今天写这篇文件主要就是为了详细参解这些方法和用途,在这个方法中有三个参数,HttpServletRequest arg0, HttpServletResponse arg1,Object arg2,前两个基本不需多说,一个http请求从客户端到服务器,以及服务器返回客户端所有的数据参数配置等都封装在这两个参数中,对于第三个参数,之前由于是为了学而学,别人教了要做登录拦截,怎么做,就完事,虽然注意过这个参数,但是也从来没当回事。

关于这第三个参数,可以说就是一个handlerMethod,是一个封装了请求地址在服务中的一些熟悉的参数 ,下面是我通过发起请求截屏的该参数的具体属性情况


具体其中的属性值就不展开了,基本上这个参数就是包括了这个请求所要到达的地址在项目中的路径,这个路径是怎么产生了beanFactory是通过xml配置文件加载启动的参数,方法的一些属性,在哪个类有哪些注解等(注意此项,就是今天的主要目的,配合自定义注解进行操作)有哪些参数都是什么等信息。总体来说对于这个方法的应用,最基本的就是类似于登录拦截器对所有的请求在执行之前进行一系列的处理。但是今天需要进行说明的就是【处理】太概念话了,深究下去,进行一系列处理可不止是一个统一的对于所有请求都需要进行固定逻辑操作的过滤,当遇到以下情况就可以利用今天所说的配合自定义注解进行操作:自己的项目需要一个拦截器对每一个请求进行一下统一操作如登录验证等,但同时却又许多请求(随着开发进度的延伸会很多而且不确定)需要跳出刚刚所制定的处理逻辑的情况,对应刚刚所说的情况有两种处理方式:

1,还是在拦截器中,还是在preHandle方法中,从request参数中取出请求的地址,与那些需要跳出统一校验的请求地址进行比较如果相同直接return true 放行

2,添加自定义注解,用@interface编写自己的自定义注解,在那些需要进行特殊处理逻辑的操作上添加自己定义的注解,然后再perHandle方法中利用第三个参数,取出

方法上的注解,然后确定是否有自定义的注解,如果有进行特殊处理(对于跳过登录校验的即为 return true)否则继续正常的过滤逻辑


对于上面所述的两种方法个人推荐第二钟,因为第一种会随着业务开发的推进越来越多需要判断,需要修改易出错,而第二种方式随着业务的推进只需在需要的时候加个注解,不需要时去掉对应的注解即可,而且特殊处理不仅仅是指跳出登录校验这么简单的业务逻辑,还有更多,各种不同的业务处理逻辑,用第二种简单明了



postHandle :这个方法在拦截器中的调用情况是,客户发出请求,server进行处理,数据返回客户端之前,进行一些校验和处理


afterCompletion: 这个方法是在一个请求响应流程完成后执行的,所以该方法中可以进行的操作一般就不涉及用户相关的操作了,可以是针对于系统的一些处理操作,比如log日志的记录,以及统一的异常处理逻辑等(因为有一个参数Exception)在开发过程中对于异常的处理,很多时候的做法就是直接抛向上一级,最后抛给了controller,但是controller又抛给了谁都没有关注过,因为基本可以理解说:这个请求过程出错了,所以客户端得不到反馈,其实controller


总结:当在我们的项目中配置了拦截器之后整个用户的请求处理流程是这样的:客户端发起请求,根据拦截规则匹配拦截器链,在拦截器中先执行preHandle,在执行request业务地址,controller处理完成后执行postHandle ,然后在执行afterCompletion,然后再回传到客户端







  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值