SpringMVC生命周期 - 整体视图

Roa*_*oam 10 spring-mvc

我是春天的新手.

我希望验证以下对SpringMVC生命周期的理解 - 将事物放在整个视图中的位置:

整个过程是由请求驱动的.

有一个Front Controller模式,Spring MVC中的Front Controller是DispatcherServlet.

在每次来自用户的传入请求时,Spring按照此处的描述管理整个生命周期.

在整体视图中,DispatcherServlet将请求分派给后端服务的控制器.完成此操作后,它会将其交给MVC的View组件,以便为响应用户准备其视图.

更详细的,

  • DispatcherServlet使用Handler来决定为该请求提供"哪个控制器".

  • 控制器应该是"轻量级" - 应该与后端的服务进程分离,作为一种良好的设计实践 - 它们包含对服务的引用并调用正确的服务.他们的"使命"是控制建立模型的服务流程,并将其交还给调度员以进行下一步.

  • View组件本身有两个部分:首先,ViewResolver为View选择正确的外观类型,以便将模型放入用户的最终格式.

从开发人员的角度来看 - DispatcherServlet是一个幕后的东西.我所做的就是在web.xml中定义并配置它(如有必要).作为开发人员,我实例化一个ApplicationContext(有很多ApplicationContext类型 - 我根据我的需要选择一个,通常是WebApplicationContext(?)).AplicationContext是使用.xml文件中的描述创建包括DispatcherServlet在内的所有servlet/bean的工厂.DispatcherServlet然后在幕后运行并管理整个过程 - 使用注释或其.xml描述,视图,处理程序,验证器等来获取和获取控制器.

我想知道这个描述是否成立 - 有效和完整,以及是否有大的缺失部分.

提前致谢.

Sot*_*lis 13

让我们一步一步详细说明

DispatcherServlet使用Handler来决定为该请求提供"哪个控制器"

DispatcherServlet保持有序ListHandlerMapping豆类(它从加载WebApplicationContext).A HandlerMapping

由定义请求和处理程序对象之间的映射的对象实现的接口.

DispatcherServlet收到请求时,它会遍历此列表,直到找到相关请求的匹配处理程序对象.为简单起见,我们只考虑一下RequestMappingHandlerMapping.

这种类型的bean 存储作为实例存储的带@RequestMapping注释方法(Method用反射检索的实际对象)的映射,HandlerMethod并包装在RequestMappingInfo包含用于匹配请求的映射数据的对象中,即.URL,标头和请求参数.

DispatcherServlet检索最佳匹配HandlerMethod从这些以及任何相应的HandlerInterceptor,你可能已经注册的情况.它将这些检索为HandlerExecutionChain对象.它首先会应用任何预先处理HandlerInterceptor秒.然后它会尝试调用你的HandlerMethod.这通常(但不总是)是@RequestMapping@Controller注释的类中的带注释的方法.这会产生Spring调用的调度结果.在DispatcherServlet随后适用,处理后HandlerInterceptor秒.它最终根据它是什么来处理调度结果.您可以查看支持的返回类型,以了解可能的内容.

控制器应该是"轻量级" - 应该与后端的服务进程分离,作为一种良好的设计实践 - 它们包含对服务的引用并调用正确的服务.他们的"使命"是控制建立模型的服务流程,并将其交还给调度员以进行下一步.

在MVC应用程序中,控制器通过更改模型来控制操作.您可以直接在控制器中执行此操作,也可以通过为此目的实施和提供服务和业务类来解耦它.控制器取决于这些,但不是相反.查看多层体系结构.

然后控制器构建可能使视图可用的模型(Model).我说可能是因为控制器可以直接产生响应,而不涉及任何视图(思考).DispatcherServlet jsp

View组件本身有两个部分:首先,ViewResolver为View选择正确的外观类型,以便将模型放入用户的最终格式.

在典型情况下控制器处理方法会返回一个Model,View,ModelAndView,String(和其他一些)对象,然后ViewResolver将处理找到正确的View.在DispatcherServlet随后试图通过像你说的第一个合并的模式来呈现这一观点.这通常意味着获取所有Model属性并将它们放入HttpServletRequest属性中.渲染步骤可能涉及渲染a jsp,生成XML或任何其他内容.

从开发人员的角度来看 - DispatcherServlet是一个幕后的东西.我所做的就是在web.xml中定义并配置它(如有必要).作为开发人员,我实例化一个ApplicationContext(有很多ApplicationContext类型 - 我根据我的需要选择一个,通常是WebApplicationContext(?)).

您实际上并不需要实例化它.该DispatcherServlet会做自己(或使用ContextLoaderListener的),当Servlet容器调用init()就可以了.它会产生自己的WebApplicationContext.你可以做的是决定使用哪个子类WebApplicationContext.如果要从XML或Java配置加载上下文,这是一个重要的选择.你可以通过提供一个<init-param>.

AplicationContext是使用.xml文件中的描述创建包括DispatcherServlet在内的所有servlet/bean的工厂.DispatcherServlet然后在幕后运行并管理整个过程 - 使用注释或其.xml描述,视图,处理程序,验证器等来获取和获取控制器.

ApplicationContext也被称为控制容器的反演.它不包括DispatcherServlet.它DispatcherServletServlet容器管理,而不是由Spring管理.但是,它主要采用Spring的ApplicationContext(WebApplicationContext)配置.它注册了它在上下文中找到的一些特殊bean. 您可以自己声明这些,或者让Spring使用这一点XML来为您完成

<mvc:annotation-driven>
Run Code Online (Sandbox Code Playgroud)

这将(主要)照顾你所描述的,即.注册处理程序,验证程序,视图等

我想知道这个描述是否成立 - 有效和完整,以及是否有大的缺失部分.

不要忘记Spring MVC Web应用程序是一个ServletWeb应用程序.因此,应用程序的生命周期与Servlet容器相关联.


DwB*_*DwB 1

你的问题没有好的答案。“当然”是我所能得到的最接近的答案。

您可以使用 xml 文件或注释或两者的组合来配置 spring。

您不需要使用 Spring MVC 编写 servlet,但如果您愿意,也可以这样做。大多数情况下,您可以(也许应该)创建控制器类(通过扩展 Spring 控制器类或使用 @Controller 注释标记类)。

控制器的“使命”是对请求进行必要的处理。他们不仅仅是“控制服务流程”

没有“将其返还”给调度员的情况。

DispatchServlet 必须在 web.xml 文件中配置,这不是可选的。

您可以(也许应该)在控制器类和您将从控制器类调用的任何 Web 服务之间有一个层。

您可以拥有多个 applicationContext 或使用单个 applicationContext。

通常,视图是一个 JSP 文件。

控制器应该添加视图使用的 DTO(数据传输对象)来显示非静态信息。 编辑:我删除了 VO 对象的提及,我(看起来像许多人一样)错误地将 DTO 和 VO 模式混为一谈。

没有“幕后”。DispatcherServlet 接收请求并将其传递给适当的控制器进行处理。

阅读Spring 框架参考的第 17 节