我是Spring的新手。
我希望验证以下对SpringMVC生命周期的理解 - 将内容置于整体视图的位置：
整个过程都是以请求为导向的。
有一个Front Controller pattern，Spring MVC中的Front Controller是DispatcherServlet。
每次来自用户的传入请求，Spring都会管理 here中描述的整个生命周期。
在整体视图中，DispatcherServlet将请求分派给后端服务的控制器。 完成此操作后，将其交给MVC的View组件，以便为响应用户准备其视图。
更详细，
DispatcherServlet使用处理程序来决定为该请求提供“哪个控制器”。
控制器应该是“轻量级” - 应该与之分离 后端的服务流程是一种良好的设计实践 - 它们包含对服务的引用并调用正确的服务。 他们的“使命”是控制建立模型和处理的服务流程 它回到调度员下一步。
View组件本身有两个部分：首先，ViewResolver为View选择正确的外观类型，以便将模型放入用户的最终格式。
从开发人员的角度来看 - DispatcherServlet是一个幕后的东西。 我所做的就是在web.xml中定义并配置它（如有必要）。 作为开发人员，我实例化一个ApplicationContext（有许多ApplicationContext类型 - 我根据我的需要选择一个，通常是 WebApplicationContext（？））。 AplicationContext是创建所有servlet / bean的工厂 DispatcherServlet，使用.xml文件中的描述。 DispatcherServlet然后在幕后运行并管理 整个过程 - 使用注释或其.xml描述来获取和获取控制器， 观点，处理程序，验证器等。
我想知道这个描述是否成立 - 有效和完整，以及是否有大量缺失。
提前致谢。
答案 0 :(得分：13)
让我们一步一步详述
DispatcherServlet使用Handler来决定要“服务于哪个控制器” 该请求
DispatcherServlet维护有序List个HandlerMapping个bean（从WebApplicationContext加载）。 HandlerMapping是
由定义其间映射的对象实现的接口 请求和处理程序对象。
当DispatcherServlet收到请求时，它会遍历此列表，直到找到相关请求的匹配处理程序对象。为简单起见，我们只考虑RequestMappingHandlerMapping。
此类型的bean存储@RequestMapping带注释的方法（通过反射检索的实际Method对象）的映射，存储为HandlerMethod个实例并包装在RequestMappingInfo个对象中保存用于匹配请求的映射数据，即。 URL，标头和请求参数。
DispatcherServlet从这些以及您可能已注册的任何相应HandlerInterceptor实例中检索最匹配的HandlerMethod。它将这些检索为HandlerExecutionChain对象。它将首先应用HandlerInterceptor个pre-handling。然后它会尝试调用您的HandlerMethod。这通常（但不总是）是@RequestMapping带注释的类中的@Controller注释方法。这产生了Spring称为调度结果的内容。 DispatcherServlet然后HandlerInterceptor应用DispatcherServlet。它最终根据它是什么来处理调度结果。 post-handling
控制器应该是“轻量级” - 应该解耦 从后端的服务流程作为一个好的设计实践 - 他们持有对服务的引用并调用正确的服务。 他们的“使命”是控制建设的服务过程 模型并将其交还给调度员以进行下一步。
在MVC应用程序中，控制器通过更改模型来控制操作。您可以直接在控制器中执行此操作，也可以通过为此目的实施和提供服务和业务类来解耦它。控制器取决于这些，但不是相反。查看You can see the supported return types for an idea of what that can be.。
控制器然后构建模型（multilayered architectures），jsp 可能使视图可用。我说可能是因为控制器可以直接产生响应而没有任何视图（想想String）。
View组件本身有两部分：首先是ViewResolver选择 View的正确类型，将模型放入最终格式 为用户。
在Controller处理程序方法返回Model，Model，View，View（以及其他一些）对象的典型情况下，{{3会找到正确的DispatcherServlet。然后Model尝试通过首先合并模型来渲染该视图。这通常意味着获取所有jsp属性并将其置于ModelAndView属性中。渲染步骤可能涉及渲染DispatcherServlet，生成XML或任何其他内容。
从开发人员的角度来看 - DispatcherServlet是一个 幕后的事情。我所做的就是定义和配置它，如果 必要的，在web.xml中。作为开发人员，我实例化了一个 ApplicationContext（有很多ApplicationContext类型 - 我选择 一个取决于我需要的，通常是WebApplicationContext（？） ）。
您实际上并不需要实例化它。当Servlet容器在其上调用init()时，WebApplicationContext会自行执行此操作（或使用ViewResolver）。它将生成自己的ApplicationContext。 HttpServletRequest。
AplicationContext是创建所有servlet / bean的工厂 包括DispatcherServlet，使用它们在.xml中的描述 文件。 DispatcherServlet然后在幕后运行并进行管理 整个过程 - 使用注释来获取和获取控制器 或者他们的.xml描述，视图，处理程序，验证器等。
DispatcherServlet也称为控制容器的反转。它不包括DispatcherServlet。 Servlet由ApplicationContext容器管理，而不是由Spring管理。但是，它主要采用Spring WebApplicationContext（<mvc:annotation-driven>
）的配置。 ContextLoaderListener What you can do is decide which subclass of WebApplicationContext to use. This is an important choice if you want to load your context from XML or from a Java configuration. You can do this by providing an <init-param>
Servlet这将（主要）照顾你所描述的，即。注册处理程序，验证程序，视图等。
我想知道这个描述是否成立 - 有效和完整，以及 是否有大片遗失。
不要忘记Spring MVC Web应用程序是Servlet Web应用程序。因此，应用程序的生命周期与{{1}}容器相关联。
答案 1 :(得分：1)
你的问题没有好的答案。 “当然”尽可能接近我。
您可以使用xml文件或注释或两者的组合来配置spring。
您不需要使用Spring MVC编写servlet，但如果您愿意，也可以。大多数情况下，您可以（可能应该）创建控制器类（通过扩展Spring控制器类或使用@Controller注释标记类）。
控制器的“任务”是执行必要的请求处理。他们不只是“控制服务流程”
调度员没有“退回”。
必须在web.xml文件中配置DispatchServlet， 这绝不是可选的。
您可以（可能应该）在您的控制器类和您将从控制器类调用的任何Web服务之间建立一个层。
您可以拥有多个applicationContexts或使用单个applicationContext。
经常没有， View是一个JSP文件。
Controller应添加视图使用的DTO（数据传输对象）以显示非静态信息。 编辑：我删除了对VO对象的提及，我（似乎很多，似乎）错误地混淆了DTO和VO模式。
没有“幕后”。 DispatcherServlet接收请求并将其传递给适当的控制器进行处理。
的第17部分