跟踪SpringMVC请求
1. 请求离开浏览器时
①
,带有用户所请求内容的信息,至少包含URL。也可能带有其他信息(如用户提交的表单信息)
-
请求的第一站是
DispatcherServlet
,这是SpringMVC
的一个前端控制器,它控制将请求分发给SpringMVC
的控制器(Controller
),由于Controller
会有多个,所以他会查询一个或者多个处理器映射(handler mapping)②
来确定将请求发到哪个Controller
- 前端控制器,前端的某些请求由它截取,之后再由它判断将请求转发给哪个组件,其实就相当于一个请求的中转站,有了这个中转站,请求的转发和响应数据的返回更加规矩、有条不紊
- 如果没有启用组件扫描让他去扫描Bean,这样的结果就是,Spring只能找到显式声明在配置类中的控制器。这样配置的话,
DispatcherServlet
会映射为应用的默认Servlet,所以它会处理所有的请求,包括对静态资源的请求,如图片和样式表(在大多数情况下,这可能并不是你想要的效果)。
-
处理器映射会根据所请求的URL来进行决策(用到过的人可以想到,这应该就是
@RequestMapping
) -
选定了合适的
Controller
之后,DispatcherServlet
把请求转发给被选中的Controller
③
,请求会在这里放下负载(所携带的信息)让Controller
处理- 其实设计良好的
Controller
本身几乎不处理工作,而是将业务逻辑委托给其他对象(们)进行处理,比如我们常见的Service
层
- 其实设计良好的
-
Controller
处理完之后,通常会返回给用户一些信息,还要返回给用户一个用于展示信息的页面,这些信息叫做模型(model)
,用来展示的页面叫做视图(view)
- 其实大家也能看出来,试图通常就是JSP,现在来说这种试图和数据一起返回的方式并不多见,一般是由前端负责展示,需要什么数据向后端要,后端只要返回数据(模型model)就行了
-
Controller
最后将要返回的模型打包,标志出用于渲染的视图名,将视图名、模型、请求一起发给DispatcherServlet
④
-
DispatcherServlet
通过视图解析器匹配一个视图文件⑤
- 由于
Controller
返回给DispatcherServlet
的只是一个视图名,而不是一个视图文件,所以DispatcherServlet
要根据视图名找到视图文件,这个过程叫做“视图解析”,完成这部分代码的对象叫做视图解析器 - 没有配置视图解析器,Spring默认会使用
BeanNameViewResolver
,这个视图解析器会查找ID与视图名称匹配的bean,并且查找的bean要实现View接口,它以这样的方式来解析视图。
- 由于
-
请求的最后一站是要被渲染的视图
⑥
,他在这里把携带的模式卸下交给视图,视图将模型数据渲染输出,这个输出会传递给客户端(不会像听上去那样硬编码)⑦
参考:《Spring In Action》第四版