手写SpringMVC源码-梳理清楚这些你也能手写出来
SpringMVC源码-手写篇
一、SpringMVC的基本结构
1.MVC简介
以前的纯Servlet的处理方式:
为了尽量减少依赖Servlet API,提高程序的可测试性、可复用性而发展出了很多的框架技术:
- Struts1
- Struts2
- SpringMVC
经典面试题:Struts2和SpringMVC的区别
- 请求映射上的区别。
- 请求数据绑定上的区别。
2.基本结构
然后我们来看看SpringMVC的基本结构
从图中我们可以得到的相关信息
- 有四个非常重要的角色
- DispatchServlet很重要
- 谁来负责Controller
- DispatchServlet根据什么规则分发请求
- View是什么
- DispatchServlet负责转发。如何知道怎么转发?
- MVC是严格的分工协作
二、控制器
接下来我们看看应该要如何来设计我们的Controller。控制器的作用是用来具体的处理用户的请求。我们系统能够通过一个普通的bean对象来作为我们的Controller。但是在Spring中对于Bean的管理都是以IoC容器来管理的。这样可以充分的利用SpringIoC和AOP的功能。
问题思考:
- 请求如何和Bean对于
- 请求如何和Bean的方法对应
1.实例级别的映射
也就是通过请求地址和Bean的名称对应。通过这个Bean来处理请求。但是如何知道用这个Bean中的哪个方法来处理呢?这时我们可以定义一个接口@Controller.然后声明对应的方法。让Bean去实现这个接口。
接下来我们需要思考:handleRequest这个方法需要返回什么信息?
也就是控制器需要返回用户需要的数据和对应的View。那么对应的返回数据应该有什么特点呢?站在我们现在这个角度我们是完全不知道应该要返回什么数据的。完全需要基于用户的需要了。也就是数据需要呈现 多样话
。这时可以通过Map来非常灵活的使用。
同时对应的View也应该具备对应的 多样化
的特点。
这里的数据和View的串联我们可以自定义一个ModelAndView这个实现来处理
所以上面的Controller中定义方法的返回值我们就可以定义为ModelAndView了
还有对应Controller对于客户的响应状态我们可以定义一个 HttpStatus
来统一管理
这种方式我们可以看到一个Bean对象处理请求的话我们还需要在 handleRequest
方法中来判断处理。或者一个Bean处理一个请求,这种方式是非常不灵活的。
2.方法级别的映射
第二种选择就是具体的请求直接映射到我们对应的方法中。我们定义的普通Bean不需要实现Controller接口了。就作为一个Controller存在。
那么怎么表示一个Bean是Controller呢?我们需要显示的通过@Controller注解来实现。
怎么映射请求到具体的方法中呢?我们可以通过@RequestMapping注解来指定
然后对应的定义如下:
3.如何实现多种方式的支持
上面我们介绍了Controller处理请求的两种方式
那如何让SpringMVC框架能够支持这两种方式呢?甚至更多的方式
我们来分析下如何来实现这种需求:
- 各种方式的请求映射是不一样的
- 各种方式对应的Request Handler 也是不一样的
- 方式一:Controller接口的实现对象
- @Controller、@RequestMapping注解标识的Bean的方法
- 如何设计DispatchServlet来灵活的处理呢
不同的方式,映射的规则不相同,请求处理器也不一样。这时我们可以考虑通过 策略模式
来处理了.对应的接口为 HandlerMapping。
然后将对应的接口的实现者设置为Bean。DispatchServlet从ApplicationContext中获取对应的配置
有了对应的handlerMapping然后怎么针对不同的请求来选择对应的实现策略呢,这时我们可以提供对应的适配器来处理。
- 每种不同的请求处理器提供它的适配实现,配置为Bean
- DispatchServlet 从ApplicationContext中获取所有配置。面向HandlerAdapter。隔绝了handler的变化影响。
方式一通过Controller接口处理还是很方便的直接只是 handlerRequest方法就可以直接处理了。但是方式二,我们通过@Controller,@RequestMapping注解来映射到对应的方法这块应该要怎么实现呢?
分析:方式二的Handler是@Controller、@RequestMapping注解标识的Bean和方法,需要定义一个实体类保存BeanName,方法名。@RequestMapping的注解信息。
定义 RequestMappingInfo
来存储对应的注解信息。那么这个注解信息该由谁去获取呢?并且在什么时候获取呢?这时我们可以在RequestMappingHandlerMapping的getHandler方法之前处理这个解析就可以了。
我们实现者两个接口来做这个事情就可以了。
还有一个问题。如果存放检测到的RequestMappingInfo信息呢。如下
4. DispatchServlet
到这我们就把Controller怎么找到的路径讲解清楚了,然后来看下DispatchServlet是如何处理的,我们应该怎么来设计。
我们先来考虑下DispatchServlet要具备哪些功能
- 创建ApplicationContext容器
- 要从容器中获取HandlerMapping、HandlerAdapter
- 完成分发
- 完成view转发
- 完成异常处理
然后我们得考虑DispatchServlet要完成这些事情,它应该怎么去实现?
那么对应的操作:
- 在init方法中完成3个属性的初始化
- 在service方法中完成handler分发、执行的逻辑
- 在destory方法中关闭ApplicationContext
对应的DispatcherServlet 应该的结构
对应的核心代码
service方法
doDispatch方法
三、Model&View
上面介绍请求了怎么分发到Controller来处理请求,接下来我们就需要看看处理完请求后如何响应对应的 数据
和 View
。
1.View
我们再回看下前面介绍的HandlerAdapter。
可以看到对应的handle方法统一返回的是ModelAndView对象。我们需要在方法中创建他的实例,提供对应的View对象。这样Controller的方法的职责就不专一了,被污染了。而且不能灵活的替换View层了。不够灵活。这时我们可以重新定义ModelAndView。再其中加入一个视图名称。
加入视图名称后,我们在Controller中的方法返回就可以如下的写法了
但是有有了一个新的问题,最终的ModelAndView对象由谁来完成呢?根据前面的讲解我们肯定能想到通过 HandlerAdapter
来实现了。
当然这块我们还有一些其他的疑问
- Model数据怎么获取?–》参数传递
- 还可以直接返回ModelAndView吗? --》完全可以
- 返回的是视图名称。怎么转换为View呢?谁来转换呢? --》专门设计一个来处理
3.ViewResolver
定义一个ViewResolver完成视图名到视图的转换。刚开始不知道怎么干,直接定义一个接口
不同的视图技术可能有不同的View实现及转换规则。那就实现ViewResolver来提供对应的转换规则。都配置为Bean。DispatcherServlet可以从容器中获取。
需要在DispatcherServlet中完成它的初始化以及对应的视图渲染逻辑。
然后来看看ViewResolver的实现。一个基于URL的转发,重定义的ViewResolver实现
增加其他的ViewResolver实现
增加其他的View实现
2.Model
数据存储Model的设计,相对就比较简单了。
四、HandlerInterceptor
上面介绍了那么多还是有问题没有涵盖到,比如请求参数如何绑定到方法参数?需要对请求进行一些过滤,再交给Handler处理。
这些其实都可以交给HandlerInterceptor来处理的。