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. publicclassXmlWebApplicationContextextendsAbstractRefreshableWebApplicationContext{
3. /**Defaultconfiglocationfortherootcontext*/
4. //这里是设置缺省BeanDefinition的地方，在/WEB-INF/applicationContext.xml文件里，如果不特殊指定其他文件，IoC容器会从这里读取BeanDefinition来初始化IoC容器
5. publicstaticfinalStringDEFAULT_CONFIG_LOCATION="/WEB-INF/applicationContext.xml";
7. /**Defaultprefixforbuildingaconfiglocationforanamespace*/
8. publicstaticfinalStringDEFAULT_CONFIG_LOCATION_PREFIX="/WEB-INF/";
10. /**Defaultsuffixforbuildingaconfiglocationforanamespace*/
11. publicstaticfinalStringDEFAULT_CONFIG_LOCATION_SUFFIX=".xml";
12. //我们又看到了熟悉的loadBeanDefinition,就像我们前面对IOC容器的分析一样，这个加载过程在容器refresh()时启动。
13. protectedvoidloadBeanDefinitions(DefaultListableBeanFactorybeanFactory)throwsIOException{
14. //CreateanewXmlBeanDefinitionReaderforthegivenBeanFactory.
15. //对于XmlWebApplicationContext,当然是使用XmlBeanDefinitionReader来对BeanDefinition信息进行解析
16. XmlBeanDefinitionReaderbeanDefinitionReader=newXmlBeanDefinitionReader(beanFactory);
18. //Configurethebeandefinitionreaderwiththiscontext's
19. //resourceloadingenvironment.
20. //这里设置ResourceLoader,因为XmlWebApplicationContext是DefaultResource的子类，所以这里同样会使用DefaultResourceLoader来定位BeanDefinition
21. beanDefinitionReader.setResourceLoader(this);
22. beanDefinitionReader.setEntityResolver(newResourceEntityResolver(this));
24. //Allowasubclasstoprovidecustominitializationofthereader,
25. //thenproceedwithactuallyloadingthebeandefinitions.
26. initBeanDefinitionReader(beanDefinitionReader);
27. //这里使用定义好的XmlBeanDefinitionReader来载入BeanDefinition
28. loadBeanDefinitions(beanDefinitionReader);
29. }
32. protectedvoidinitBeanDefinitionReader(XmlBeanDefinitionReaderbeanDefinitionReader){
33. }
36. //如果有多个BeanDefinition的文件定义，需要逐个载入，都是通过reader来完成的，这个初始化过程是由refreshBeanFactory方法来完成的，这里只是负责载入BeanDefinition
37. protectedvoidloadBeanDefinitions(XmlBeanDefinitionReaderreader)throwsBeansException,IOException{
38. String[]configLocations=getConfigLocations();
39. if(configLocations!=null){
40. for(StringconfigLocation: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. protectedObjectgetHandlerInternal(HttpServletRequestrequest)throwsException{
2. //这里从request中得到请求的url路径
3. StringlookupPath=this.urlPathHelper.getLookupPathForRequest(request);
4. //这里使用得到的url路径对Handler进行匹配，得到对应的Handler，如果没有对应的Hanlder，返回null，这样默认的Handler会被使用
5. Objecthandler=lookupHandler(lookupPath,request);
6. if(handler==null){
7. //Weneedtocareforthedefaulthandlerdirectly,sinceweneedto
8. //exposethePATH_WITHIN_HANDLER_MAPPING_ATTRIBUTEforitaswell.
9. ObjectrawHandler=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+"]tohandler'"+handler+"'");
23. }
24. elseif(handler==null&&logger.isTraceEnabled()){
25. logger.trace("Nohandlermappingfoundfor["+lookupPath+"]");
26. }
27. returnhandler;
28. }
29. //lookupHandler是根据url路径，启动在handlerMap中对handler的检索，并最终返回handler对象
30. protectedObjectlookupHandler(StringurlPath,HttpServletRequestrequest)throwsException{
31. //Directmatch?
32. Objecthandler=this.handlerMap.get(urlPath);
33. if(handler!=null){
34. validateHandler(handler,request);
35. returnbuildPathExposingHandler(handler,urlPath,null);
36. }
37. //Patternmatch?
38. StringbestPathMatch=null;
39. for(StringregisteredPath: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. StringpathWithinMapping=getPathMatcher().extractPathWithinPattern(bestPathMatch,urlPath);
49. Map<String,String>uriTemplateVariables=
50. getPathMatcher().extractUriTemplateVariables(bestPathMatch,urlPath);
51. returnbuildPathExposingHandler(handler,pathWithinMapping,uriTemplateVariables);
52. }
53. //Nohandlerfound...
54. returnnull;
55. }

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

Java代码

1. protectedvoiddoDispatch(HttpServletRequestrequest,HttpServletResponseresponse)throwsException{
2. HttpServletRequestprocessedRequest=request;
3. HandlerExecutionChainmappedHandler=null;
4. intinterceptorIndex=-1;
5. //这里为视图准备好一个ModelAndView，这个ModelAndView持有handler处理请求的结果
6. try{
7. ModelAndViewmv=null;
8. booleanerrorView=false;
9. try{
10. processedRequest=checkMultipart(request);
11. //Determinehandlerforthecurrentrequest.
12. //根据请求得到对应的handler,hander的注册以及getHandler的实现在前面已经分析过
13. mappedHandler=getHandler(processedRequest,false);
14. if(mappedHandler==null||mappedHandler.getHandler()==null){
15. noHandlerFound(processedRequest,response);
16. return;
17. }
18. //ApplypreHandlemethodsofregisteredinterceptors.
19. //调用hander的拦截器，从HandlerExecutionChain中取出Interceptor进行前处理
20. HandlerInterceptor[]interceptors=mappedHandler.getInterceptors();
21. if(interceptors!=null){
22. for(inti=0;i<interceptors.length;i++){
23. HandlerInterceptorinterceptor=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. //Actuallyinvokethehandler.
32. //这里是实际调用handler的地方，在执行handler之前，用HandlerAdapter先检查一下handler的合法性：是不是按Spring的要求编写的handler
33. //handler处理的结果封装到ModelAndView对象，为视图提供展现数据
34. HandlerAdapterha=getHandlerAdapter(mappedHandler.getHandler());
35. //这里通过调用HandleAdapter的handle方法，实际上触发对Controller的handleRequest方法的调用
36. mv=ha.handle(processedRequest,response,mappedHandler.getHandler());
37. //Doweneedviewnametranslation?
38. if(mv!=null&&!mv.hasView()){
39. mv.setViewName(getDefaultViewName(request));
40. }
41. //ApplypostHandlemethodsofregisteredinterceptors.
42. if(interceptors!=null){
43. for(inti=interceptors.length-1;i>=0;i--){
44. HandlerInterceptorinterceptor=interceptors[i];
45. interceptor.postHandle(processedRequest,response,mappedHandler.getHandler(),mv);
46. }
47. }
48. }
49. catch(ModelAndViewDefiningExceptionex){
50. logger.debug("ModelAndViewDefiningExceptionencountered",ex);
51. mv=ex.getModelAndView();
52. }
53. catch(Exceptionex){
54. Objecthandler=(mappedHandler!=null?mappedHandler.getHandler():null);
55. mv=processHandlerException(processedRequest,response,handler,ex);
56. errorView=(mv!=null);
57. }
58. //Didthehandlerreturnaviewtorender?
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("NullModelAndViewreturnedtoDispatcherServletwithname'"+getServletName()+
69. "':assumingHandlerAdaptercompletedrequesthandling");
70. }
71. }
72. //Triggerafter-completionforsuccessfuloutcome.
73. triggerAfterCompletion(mappedHandler,interceptorIndex,processedRequest,response,null);
74. }
75. catch(Exceptionex){
76. //Triggerafter-completionforthrownexception.
77. triggerAfterCompletion(mappedHandler,interceptorIndex,processedRequest,response,ex);
78. throwex;
79. }
80. catch(Errorerr){
81. ServletExceptionex=newNestedServletException("Handlerprocessingfailed",err);
82. //Triggerafter-completionforthrownexception.
83. triggerAfterCompletion(mappedHandler,interceptorIndex,processedRequest,response,ex);
84. throwex;
85. }
86. finally{
87. //Cleanupanyresourcesusedbyamultipartrequest.
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 楼 accphc2009-12-24 引用

看源代码费劲。

5 楼 jiwenke2009-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 楼 jiwenke2009-11-09 引用

dieslrae 写道

看了，struts写错了 =。=

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

3 楼 erikchang2009-11-09 引用

引用

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

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

2 楼 guolimin198211182009-11-09 引用

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

1 楼 dieslrae2009-11-09 引用

看了，struts写错了 =。=