本篇主要介绍Spring Boot的统一功能处理中的拦截器。
目录
一、拦截器的基本使用
二、拦截器实操
三、浅尝源码
初始化DispatcherServerlet
处理请求(doDispatch)
四、适配器模式
一、拦截器的基本使用
在一般的学校或者社区门口,通常会安排几个保安大爷来进行身份验证,只有身份符合要求的人才会被放行,否则则会被大爷拦住,而拦截器就像我们程序的保安大爷,只有通过我们自己定义的拦截规则,请求才能被放行到目标接口上。
下面我们来看看如何在Spring Boot中使用拦截器
在项目中设置拦截,我们需要先自己定义一些拦截器,里面包含一些具体的拦截规则,定义拦截器的代码如下:
(1)首先创建一个拦截类,通常以“Interceptor”作为类名的后半部分,这里我们定义一个LoginInterceptor类,意为与登录相关的拦截器,然后让该类实现一个HandlerInterceptor接口,具体如下:
@Component
public class LoginInterceptor implements HandlerInterceptor {}
(2)重写三个方法:
@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {}@Overridepublic void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {}@Overridepublic void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {}
其中preHandle为在目标方法执行前要执行的方法,其返回值如果为true,则会被放行去执行目标方法,为false则拦截,我们可以在这个方法里根据需求定义拦截规则。postHandle为目标方法执行后要执行的方法。afterCompletion为最后视图渲染完后最后执行的方法(由于现在都是前后端分离了,后端一般不处理视图,因此这个方法不需要过多了解)。
定义好拦截器后我们还需要配置拦截器,具体配置流程如下:
(1)创建配置类(一般以Config结尾,这里以为WebConfig),实现WebMvcConfigurer接口:
public class WebConfig implements WebMvcConfigurer {
}
(2)然后重写addInterceptor方法
@Overridepublic void addInterceptors(InterceptorRegistry registry) {}
(3)然后我们在里面添加我们需要配置的拦截器,具体如下:
这里我们可以通过@Autowired注入一个LoginInterceptor对象,也可以直接在参数里new一个,只要是传入一个实现前面的HandlerInterceptor接口的类的对象即可。
(4)然后在配置我们需要拦截的路径(即请求url中ip地址端口号的后面的部分):
这里的”/**"表示任意路径,例如“/user/book、/user”等,另外还有“/*"他只能表示一级路径,例如:
”/user,/book"等。
(4)由于通常我们并不需要所有路径都进行拦截(例如登录请求),因此我们还需要排除一些路径,让这些路径不被拦截,具体如下:
(5)最后我们还需要把这个类放到Spring容器里,由于这里与配置相关,所有使用@Configuration。
二、拦截器实操
接下来我们来实操一下。首先我们创建一个Controller类,在里面定义一个login方法(这里只是简单测试一下,不进行密码校验,只是给用户设置一个登录状态而已):
然后再添加几个测试方法:
然后我们再来定义一下拦截器,再preHandle方法中设置一下拦截规则,只有处于登录状态才能放行 ,并在另外两个方法中打印日志来进行观察:
然后在注册(配置)一下拦截器(不拦截login方法,其他全部拦截) :
最后我们通过postMan构造请求来访问一下这些方法.
先访问一下test01
可以发现返回的响应为空,也就是说请求被拦截器拦截到了。
然后我们再来访问一下login
可以发现响应有数据了,但由于我们请求中没有传值,导致接口中的两个参数为空,所以返回了false。接下来我们补上这两个值再访问一下
可以发现响应中返回true了,同时这也意味着我们现在已经给用户设置成登录状态了,此时我们再来访问test01
可以发现响应已经有数据了。这也就意味着这个请求已经被拦截器放行了。
最后我们再来看一下 控制台的日志:
可以发现,拦截器是严格按照顺序执行相关方法的 ,如果请求被拦截了,则只会执行postHandle方法就返回了,如果请求被放行则会按顺序执行完拦截器中的三个方法。并且对于配置中没有涉及到的路径,和被排除的路径,则根本不会进入到拦截器。
三、浅尝源码
接下来,我们来浅浅阅读一下与拦截器相关的部分源码。
初始化DispatcherServerlet
仔细观察日志可以发现,当我们的服务器接收到第一个来自前端的请求时,会初始化一个dispatcherServerlet类。
它的初始化方法为init(),具体实现是在其父类HttpServerletBean中实现的
init方法首先创建了一个PropertyValues类,这个类我并不知道是干嘛的,但根据其名称可以大体猜出来应该是去读一些配置,并且下面的if语句 判断这个对象是否为空,不为空才去执行相关逻辑,因此可以推测出if语句里应该是去根据读到的配置去进行一些设置。在init方法最后执行了一个initServerletBean方法,,我们来具体看一下这个方法,
转到定义可以发现HttpServerletBean中并未实现这个方法,接下来我们去其子类看一下
可以发现其子类FrameworkServerlet重写了这个方法,并具体进行了实现。仔细观察可以发现这个方法主要是在打印日志,日志的内容就是我们在前面控制台所看到的
并且 这里还进行了计时,并打印在了日志里。除去日志的部分可以发现这个方法就只剩下try-catch中的内容了:
接下来我们继续进入到其中的initWebAppliactionContext ()来看一下,
根据名字可以发现这个方法应该是用来 初始化WebApplicationContext的,并且通过代码大致可以发现这个方法会先去从类的成员属性中获取WebAppliactionContext,如果成员属性不为空,则会直接用成员属性的,如果为空,则调用findWebApplication去寻找一个并使用,如果没找到,则去创建一个。执行完上面第一个红框里的内容后,wac应该是已经不再为空了的,接下来调用onRefresh方法,可以发现这里加了锁来防止线程安全问题。接下来我们进到onRefresh方法来看一下:
可以发现FrameWorkServerlet中并未进行实现,我们再进到其子类看一下:
可以发现子类进行了实现,并且此时这个子类就是我们要初始化的DispatchServerlet。然后我们再看看这个方法里使用的initStrategies()方法:
通过方法名称可以发现这个方法是在进行一些初始化,然后再通过具体代码可以发现这个方法初始化了九个组件,这些组件就是Spring的九大组件,其名称如下:
- MultipartResolver:文件上传解析器
- LocaleResolver:区域解析器
- ThemeResolver:主题解析器
- HandlerMappings:处理器映射器
- HandlerAdapters:处理器适配器
- HandlerExceptionResolvers:异常处理器解析器
- RequestToviewNameTranslator:视图名称转换器
- ViewResolvers:视图解析器
- FlashMapManager:FlashMap管理器
初始化这些组件后,DispatchServerlet就初始化完了。
处理请求(doDispatch)
初始化完成后,DispatchServerlet就能进行请求的处理了,处理请求,主要通过DispatchServerlet类的doDispatch方法来对请求调度给Controller来执行,下面我们来详细看一下这个方法:
首先它会去获取一个与请求对应的处理器,然后再根据处理器去获取一个能够使用的适配器
然后再根据适配器来顺序执行拦截器的相关方法以及目标方法 然后处理视图,并执行最后的afterCompletion方法
四、适配器模式
在前面浅尝源码时,提到了适配器这个概念,适配器使用到了一种设计模式 --- 适配器模式。适配器模式能将一个类的接口,转换成符合客户期待的接口,从而使原本并不能兼容使用的接口也能使用了。简单来说,就是有一个接口,由于兼容问题并不能直接使用,需要在中间加上一个适配器才能够使用这个接口。例如我们生活中的转接头,当我们的手机是Type_c的充电口,而我们却只有苹果的数据线时,这根苹果的数据线自然是冲不了我们的手机的,此时就需要一个转接头了,通过转接头,我们就可以给手机充电了。此处转接头就相当于我们的的适配器,而转接头的设计就相当于是是适配器模式这种设计思想
可能有人会说为什么 不在一开始就设计成兼容的接口呢,这样就没必要大费周章弄一个适配器了,这样固然好,但人并不是万能的,总会有我们意想不到的情况出现,面面俱到几乎是不可能的,就像使用Type-c接口的手机厂商肯定不会想到有人会用苹果的数据线来充电,但既然这个需求是存在的,也就不能不去实现了,重新设计的话,成本又太高,因此,就只能使用适配器这一无奈之举了。