深入解析SpringMVC主要角色

1.HandleMapping

1. HandlerMapping帮助DispatcherServlet进行Web请求的URL到具体处理类的匹配。
2. DispatcherServlet在选用HandlerMapping的过程中，将根据我们所指定的一系列HandlerMapping的优先级进行排序，如果当前的HandlerMapping能够返回可用的Handler，则使用该Handler进行请求的处理，而不再继续询问其他的HandlerMapping。否则，将继续按照优先级进行询问，直到获取一个可用的Handler为止。
3. HandlerMapping的优先级规定遵循Spring框架一贯的Ordered接口所规定的语义。如果不明确指定order，那么默认值为Integer.MAX_VALUE，对应最低优先级。

2.Controller

以BaseCommandController为首的规范操作一派，对Web处理过程中的某些通用逻辑做了进一步的规范化封装处理，规范化的方面主要包括：

自动抽取请求参数并绑定到指定的Command对象。

提供了统一的数据验证方式。

规范化了表单请求的处理流程，并且对简单的多页面表单请求处理提供支持。

1. AbstractController
   1、它是整个Controller继承层次的起源。该类通过模板方法模式解决了：
   管理当前Controller所支持的请求方法类型(GET/POST)
   管理页面的缓存设置，即是否允许浏览器缓存当前页面
   管理执行流程在会话Session上的同步
   而我们要做的，只不过是在公开的HandlerRequestInternal(request，response)模板方法中实现具体Web请求处理过程中的其他逻辑。
   2、虽然直接继承AbstractController实现Web处理逻辑没有太多限制，但往往需要关注太多的细节。所以，只有对于简单的Web请求，可以采用。
2. MultiActionController
   1、对于CRUD这类逻辑上相近的Web请求来说，可以交给MultiActionController来统一处理，而不用分别单独实现。
   2、还提供了一下功能：
   请求参数到Command对象的绑定。
   通过Validator的数据验证。
   细化的异常处理方法
   3、助理MethodNameResolver的主要工作就是帮助决定当前请求应该交给哪个方法来处理
   4、其中定义的方法不允许重载，所以映射中需要指定方法名即可，不需要任何参数信息
   5、如果涉及单一复杂的表单交互，尽量使用SimpleFormController。
3. SimpleFormController
   1、继承了BaseCommandController的自动数据绑定(帮助我们自动提取HttpServletRequest中的相应参数，然后转型为需要的对象类型，我们唯一要做的就是为数据绑定提供一个目标Command对象，此后的Web处理逻辑直接同数据绑定的Command对象打交道即可)和通过Validator的数据验证功能。专门面向单一表单的处理。
   2、数据绑定：
   (1)在Web请求到达之后，提取当前请求中的所有参数名称，然后遍历它，以获取对应每个参数的值，获取的参数名和参数值放入一个PropertyValue中。最终将拥有所有需要绑定的参数和参数值的一个集合。
   (2)有了即将绑定到目标Command对象的数据来源之后，即可将这些数据根据Command对象中各个域属性定义的类型进行数据转型，然后设置到Command对象上。
   BeanWrapperImpl会将Command对象纳入自身管理范围。然后比照参数名与Command对象的属性对应关系，以进行设置。而类型差异性的转换工作，则由BeanWrapperImpl所依赖的一系列自定义PropertyEditor负责。
   3、Validator具体实现类可以在执行验证逻辑的过程中，随时将验证中的错误信息添加到通过方法参数传入的Errors对象内。这样，验证逻辑执行完成后，就可通过Errors检索验证结果了。
   一个Validator实现类，首先应该通过supports(Class)方法界定自身负责的验证范围，然后才是具体验证逻辑。
4. AbstractWizardFormController
   1、适用于这种向导式的简单的多页面流程实现。

3.ModelAndView

1. 通常，Controller在将Web请求处理完成后，会返回一个ModelAndView实例。该ModelAndView实例将包含两部分内容，一部分为视图相关内容，可以是逻辑视图名称，也可以是具体的View实例。另一部分则是模型数据，视图渲染过程中将会把这些模型数据合并入最终的视图输出。所以，简单来说，ModelAndView实际上就是一个数据对象，不过通过该数据对象，却可以解决具体的Web请求处理Controller与视图渲染之间的紧密耦合，使得2个方面能够独立演化。
2. ModelAndView以ModelMap的形式来保存模型数据，通过构造方法传入的或者通过实例方法添加的模型数据都将添加到这个ModelMap中。至于ModelMap中保存的模型数据将会在视图渲染阶段，由具体的View实现类来获取并使用。

4.视图定位器ViewResolver

1. 根据Controller所返回的ModelAndView中的逻辑视图名，为DispatcherServlet返回一个可用的View实例。
2. 大部分的ViewResolver实现类，除了BeanNameViewResolver是直接实现ViewResolver接口，都直接或间接继承自AbstractCachingViewResolver。因为针对每次请求都重新实例化View将带来性能上的损失。所以Spring MVC在AbstractCachingViewResolver这一继承层次加入了View实例的缓存功能。默认开启，对于生产环境来说，这是合理的默认值。不过，在测试或开发环境下，向即刻反映相应的修改结果，可以关闭缓存。
3. DispatcherServlet不但可以接受多个HandleMapping以处理请求到具体Handler的映射，也可以接受多个ViewResolver以处理视图的查找。
4. 如果为DispatcherServlet指定多个ViewResolver的话，不要给予InternalR的机会。esourceViewResolver和其他UrlBasedViewResolver子类过高的优先级，因为这些ViewResolver即使找不到相应的视图，也不会返回null给我们轮询下一个ViewResolver。

5.各司其职的View

1. View是SpringMVC中将原本可能存在于DispatcherServlet中的视图渲染逻辑得以剥离出来的关键组件。通过引入该策略抽象接口，我们可以极具灵活性地支持各种视图渲染技术。
2. 各种View实现类主要的职责就是在render方法中实现最终的视图渲染工作。
3. JSP模板文件与模型数据的合并操作将由Web容器(如Tomcat)来完成。