Spring技术内幕——深入解析Spring架构与设计原理（四）Web MVC的实现

以前的欠账，现在补上，欢迎指正和讨论。 

Spring Web MVC的实现 
关于MVC，这是和WEB开发相关的部分，显然大家都是很熟悉了。从最初的JSP到struts，再到像wicket等等，真是百花齐放，百家争鸣.在WEB UI上，这部分是做web应用架构选择不可缺少的一部分。而作为MVC框架，也许SPRING MVC不能算得上是表现力最出色的UI框架，但无疑，它的实现也是非常的优秀，同时，我们可以从它的实现上，看到一个非常清晰的MVC实现的过程，从这点上看，真是非常的过瘾啊！ 

在了解IOC容器的基本实现的基础上，下面我们来看看，在典型的Web环境中，Spring IOC容器是如何在Web环境中被载入并起作用的。我们可以看到，对于MVC这部分，主要建立在IOC的基础上，AOP的特性应用得并不多。Spring并不是天生就能在Web容器中起作用的，同样也需要一个启动过程，把自己的IOC容器导入，并在Web容器中建立起来。 

与对IoC容器的初始化的分析一样，我们同样看到了loadBeanDefinition对BeanDefinition的载入。在Web环境中，对定位BeanDefinition的Resource有特别的要求，对这个要求的处理体现在getDefaultConfigLocations方法的处理中。可以看到，在这里，使用了默认的BeanDefinition的配置路径，这个路径在XmlWebApplicationContext中，已经作为一个常量定义好了，这个常量就是/WEB-INF/applicationContext.xml。这里的loadBeanDefinition实现如下所示： 

Java代码  

1. public class XmlWebApplicationContext extends AbstractRefreshableWebApplicationContext {  
2.   
3.     /** Default config location for the root context */  
4.     //这里是设置缺省BeanDefinition的地方，在/WEB-INF/applicationContext.xml文件里，如果不特殊指定其他文件，IoC容器会从这里读取BeanDefinition来初始化IoC容器  
5.     public static final String DEFAULT_CONFIG_LOCATION = "/WEB-INF/applicationContext.xml";  
6.   
7.     /** Default prefix for building a config location for a namespace */  
8.     public static final String DEFAULT_CONFIG_LOCATION_PREFIX = "/WEB-INF/";  
9.   
10.     /** Default suffix for building a config location for a namespace */  
11.     public static final String DEFAULT_CONFIG_LOCATION_SUFFIX = ".xml";  
12.     //我们又看到了熟悉的loadBeanDefinition,就像我们前面对IOC容器的分析一样，这个加载过程在容器refresh()时启动。  
13.     protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {  
14.         // Create a new XmlBeanDefinitionReader for the given BeanFactory.  
15.         // 对于XmlWebApplicationContext,当然是使用XmlBeanDefinitionReader来对BeanDefinition信息进行解析  
16.         XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);  
17.   
18.         // Configure the bean definition reader with this context's  
19.         // resource loading environment.  
20.         // 这里设置ResourceLoader,因为XmlWebApplicationContext是DefaultResource的子类，所以这里同样会使用DefaultResourceLoader来定位BeanDefinition       
21.         beanDefinitionReader.setResourceLoader(this);  
22.         beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));  
23.   
24.         // Allow a subclass to provide custom initialization of the reader,  
25.         // then proceed with actually loading the bean definitions.  
26.         initBeanDefinitionReader(beanDefinitionReader);  
27.         //这里使用定义好的XmlBeanDefinitionReader来载入BeanDefinition  
28.         loadBeanDefinitions(beanDefinitionReader);  
29.     }  
30.   
31.   
32.     protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {  
33.     }  
34.   
35.   
36.     //如果有多个BeanDefinition的文件定义，需要逐个载入，都是通过reader来完成的，这个初始化过程是由refreshBeanFactory方法来完成的，这里只是负责载入BeanDefinition  
37.     protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {  
38.         String[] configLocations = getConfigLocations();  
39.         if (configLocations != null) {  
40.             for (String configLocation : configLocations) {  
41.                 reader.loadBeanDefinitions(configLocation);  
42.             }  

进入DispatcherServlet和MVC实现 
完成了在Web环境中，IoC容器的建立以后，也就是在完成对ContextLoaderListener的初始化以后，Web容器开始初始化DispatcherServlet，接着，会执行DispatcherServlet持有的IoC容器的初始化过程，在这个初始化过程中，一个新的上下文被建立起来，这个DispatcherServlet持有的上下文，被设置为根上下文的子上下文。可以大致认为，根上下文是和Web应用相对应的一个上下文，而DispatcherServlet持有的上下文是和Servlet对应的一个上下文，在一个Web应用中，往往可以容纳多个Servlet存在；与此相对应，对于应用在Web容器中的上下体系，也是很类似的，一个根上下文可以作为许多Servlet上下文的双亲上下文。在DispatcherServlet，我们可以看到对MVC的初始化，是在DispatcherServlet的initStrategies完成的。 
在这个初始化完成以后，会在上下文中建立器一个执行器于url的对应关系，这个对应关系可以让在url请求到来的时候，MVC可以检索到相应的控制器来进行处理，如以下代码所示： 

Java代码  

1. protected Object getHandlerInternal(HttpServletRequest request) throws Exception {  
2.     //这里从request中得到请求的url路径  
3.     String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);  
4.     //这里使用得到的url路径对Handler进行匹配，得到对应的Handler，如果没有对应的Hanlder，返回null，这样默认的Handler会被使用  
5.     Object handler = lookupHandler(lookupPath, request);  
6.     if (handler == null) {  
7.         // We need to care for the default handler directly, since we need to  
8.         // expose the PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well.  
9.         Object rawHandler = null;  
10.         if ("/".equals(lookupPath)) {  
11.             rawHandler = getRootHandler();  
12.         }  
13.         if (rawHandler == null) {  
14.             rawHandler = getDefaultHandler();  
15.         }  
16.         if (rawHandler != null) {  
17.             validateHandler(rawHandler, request);  
18.             handler = buildPathExposingHandler(rawHandler, lookupPath, null);  
19.         }  
20.     }  
21.     if (handler != null && logger.isDebugEnabled()) {  
22.         logger.debug("Mapping [" + lookupPath + "] to handler '" + handler + "'");  
23.     }  
24.     else if (handler == null && logger.isTraceEnabled()) {  
25.         logger.trace("No handler mapping found for [" + lookupPath + "]");  
26.     }  
27.     return handler;  
28. }  
29.   // lookupHandler是根据url路径，启动在handlerMap中对handler的检索，并最终返回handler对象  
30. protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception {  
31.     // Direct match?  
32.     Object handler = this.handlerMap.get(urlPath);  
33.     if (handler != null) {  
34.         validateHandler(handler, request);  
35.         return buildPathExposingHandler(handler, urlPath, null);  
36.     }  
37.     // Pattern match?  
38.     String bestPathMatch = null;  
39.     for (String registeredPath : this.handlerMap.keySet()) {  
40.         if (getPathMatcher().match(registeredPath, urlPath) &&  
41.                 (bestPathMatch == null || bestPathMatch.length() < registeredPath.length())) {  
42.             bestPathMatch = registeredPath;  
43.         }  
44.     }  
45.     if (bestPathMatch != null) {  
46.         handler = this.handlerMap.get(bestPathMatch);  
47.         validateHandler(handler, request);  
48.         String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestPathMatch, urlPath);  
49.         Map<String, String> uriTemplateVariables =  
50.                 getPathMatcher().extractUriTemplateVariables(bestPathMatch, urlPath);  
51.         return buildPathExposingHandler(handler, pathWithinMapping, uriTemplateVariables);  
52.     }  
53.     // No handler found...  
54.     return null;  
55. }  

最后，我们可以结合在DispatcherServlet中，对请求的分发处理来了解一个url请求到来时，MVC的实现和协同处理过程，如以下代码所示： 

Java代码  

1. protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {  
2.     HttpServletRequest processedRequest = request;  
3.     HandlerExecutionChain mappedHandler = null;  
4.     int interceptorIndex = -1;  
5.     //这里为视图准备好一个ModelAndView，这个ModelAndView持有handler处理请求的结果  
6.     try {  
7.         ModelAndView mv = null;  
8.         boolean errorView = false;  
9.         try {  
10.             processedRequest = checkMultipart(request);  
11.             // Determine handler for the current request.  
12.             // 根据请求得到对应的handler,hander的注册以及getHandler的实现在前面已经分析过  
13.             mappedHandler = getHandler(processedRequest, false);  
14.             if (mappedHandler == null || mappedHandler.getHandler() == null) {  
15.                 noHandlerFound(processedRequest, response);  
16.                 return;  
17.             }  
18.             // Apply preHandle methods of registered interceptors.  
19.             // 调用hander的拦截器，从HandlerExecutionChain中取出Interceptor进行前处理  
20.             HandlerInterceptor[] interceptors = mappedHandler.getInterceptors();  
21.             if (interceptors != null) {  
22.                 for (int i = 0; i < interceptors.length; i++) {  
23.                     HandlerInterceptor interceptor = interceptors[i];  
24.                     if (!interceptor.preHandle(processedRequest, response, mappedHandler.getHandler())) {  
25.                         triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null);  
26.                         return;  
27.                     }  
28.                     interceptorIndex = i;  
29.                 }  
30.             }  
31.             // Actually invoke the handler.  
32.             // 这里是实际调用handler的地方，在执行handler之前，用HandlerAdapter先检查一下handler的合法性：是不是按Spring的要求编写的handler  
33.             // handler处理的结果封装到ModelAndView对象，为视图提供展现数据  
34.             HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());  
35.             //这里通过调用HandleAdapter的handle方法，实际上触发对Controller的handleRequest方法的调用  
36.             mv = ha.handle(processedRequest, response, mappedHandler.getHandler());  
37.             // Do we need view name translation?  
38.             if (mv != null && !mv.hasView()) {  
39.                 mv.setViewName(getDefaultViewName(request));  
40.             }  
41.             // Apply postHandle methods of registered interceptors.  
42.             if (interceptors != null) {  
43.                 for (int i = interceptors.length - 1; i >= 0; i--) {  
44.                     HandlerInterceptor interceptor = interceptors[i];  
45.                     interceptor.postHandle(processedRequest, response, mappedHandler.getHandler(), mv);  
46.                 }  
47.             }  
48.         }  
49.         catch (ModelAndViewDefiningException ex) {  
50.             logger.debug("ModelAndViewDefiningException encountered", ex);  
51.             mv = ex.getModelAndView();  
52.         }  
53.         catch (Exception ex) {  
54.             Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);  
55.             mv = processHandlerException(processedRequest, response, handler, ex);  
56.             errorView = (mv != null);  
57.         }  
58.         // Did the handler return a view to render?  
59.         // 这里使用视图对ModelAndView数据的展现  
60.         if (mv != null && !mv.wasCleared()) {  
61.             render(mv, processedRequest, response);  
62.             if (errorView) {  
63.                 WebUtils.clearErrorRequestAttributes(request);  
64.             }  
65.         }  
66.         else {  
67.             if (logger.isDebugEnabled()) {  
68.                 logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() +  
69.                         "': assuming HandlerAdapter completed request handling");  
70.             }  
71.         }  
72.         // Trigger after-completion for successful outcome.  
73.         triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null);  
74.     }  
75.     catch (Exception ex) {  
76.         // Trigger after-completion for thrown exception.  
77.         triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);  
78.         throw ex;  
79.     }  
80.     catch (Error err) {  
81.         ServletException ex = new NestedServletException("Handler processing failed", err);  
82.         // Trigger after-completion for thrown exception.  
83.         triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);  
84.         throw ex;  
85.     }  
86.     finally {  
87.         // Clean up any resources used by a multipart request.  
88.         if (processedRequest != request) {  
89.             cleanupMultipart(processedRequest);  
90.         }  
91.     }  
92. }  

通过MVC框架，实际上是DispatcherServlet的协调运作，得到了ModelAndView对象作为数据处理结果，最后，DispatcherServlet把获得的模型数据交给特定的视图对象，从而完成这些数据的视图呈现工作，这个视图呈现由视图对象的render方法来完成，毫无疑问，对应于不同的视图对象，render方法会完成不同的视图呈现处理，从而为用户提供丰富的Web UI表现。关于这些不同的视图展现，还可以看到很多很有参考意义的开源软件的灵活使用，限于篇幅，这里就不详细说了。 

对Spring MVC框架的个人理解 

对Spring作为应用平台的Web应用开发而言，Spring为它们提供了Spring MVC框架，作为一个像struts这样的Web框架的替代；当然，作为应用平台，Spring并不会强制应用对Web框架的选择。但对Web应用开发而言，选择直接使用Spring MVC，可以给应用开发带来许多便利。因为Spring MVC, 毫无疑问，很好的提供了与Web环境中的IoC容器的集成。同时，和其他Web应用一样，使用Spring MVC, 应用只需要专注于处理逻辑和视图呈现的开发（当然这些开发需要符合Spring MVC的开发习惯），在视图呈现部分，Spring MVC同时也集成了许多现有的Web UI实现，比如像Excel, PDF这些文档视图的生成，因为，集成第三方解决方案，实在可以说是Spring的拿手好戏，从这种一致性的开发模式上看，它在很大程度上降低了Web应用开发的门槛。 

评论

6 楼  accphc 2009-12-24    引用

看源代码费劲。

5 楼  jiwenke 2009-11-09    引用

erikchang 写道

引用

作为应用平台，Spring并不会强制应用对Web框架的选择。但对Web应用开发而言，选择直接使用Spring MVC，可以给应用开发带来许多便利

支持楼主的看法，SpringMVC确实是个不错的选择，方便实用，而且能够更好的和SpringIOC等功能结合起来使用，只是现在SSH的风吹的太烈的，很多人都有跟风的感觉！

SSH已经是江湖上极为流行的组合了，但由于我个人在WEB UI上涉及较晚，倒是没有受到struts的影响，可以说是对它是一窍不通，我在WEB UI上用的框架是Wicket，当然还有Spring MVC，我感觉都是很好用的一个框架。和Spring的耦合性也不高，我挺喜欢它的，可能是自己见识少，坐井观天的缘故吧。 
Wicket的开发和SWING的开发很像，而SPRING MVC因为是SPRING中的一个组件，所以可以说是各有特点。 

4 楼  jiwenke 2009-11-09    引用

dieslrae 写道

看了，struts写错了 =。=

太感谢你了！！已经改正了。

3 楼  erikchang 2009-11-09    引用

引用

作为应用平台，Spring并不会强制应用对Web框架的选择。但对Web应用开发而言，选择直接使用Spring MVC，可以给应用开发带来许多便利

支持楼主的看法，SpringMVC确实是个不错的选择，方便实用，而且能够更好的和SpringIOC等功能结合起来使用，只是现在SSH的风吹的太烈的，很多人都有跟风的感觉！

2 楼  guolimin19821118 2009-11-09    引用

文章都非常好 
不过源码我看的特别费劲 

1 楼  dieslrae 2009-11-09    引用

看了，struts写错了 =。=