springMVC执行过程..docVIP

其实每个MVC frameworkrequest过来时，它都通过一个Servlet来响应request，再根据request的路径名和配置将这个request dispatch给一个Controller执行，最后将之返回配置文件里对应的页面。在Spring MVC里，这个Servlet的名字叫DispatchServlet。稍看一下它的源码会发现这是一很简单的类。 下面是DispatchServlet的类图: 简单吧，这是典型的Template Method模式。每个类都会完成一些自己的本职工作，把不属于自己的工作延迟到子类来完成。这些类的子职责在下面会有分析。其实整个SpringFramework用的最多的模式就是Template Method（Strategy也挺多，呵呵），也许任何Framework用的最多的都是Template Method模式。Why?看看Expert One on One J2EE Design and Development吧，至少Template Method和Strategy模式的分析这本书甚至比Head first Design Pattern还好。 我们先来看DispatchServlet的初始化执行过程分析吧： 我们知道每个Servlet在Web服务器启动时都会有一个初始化的机会，这就是Servlet的init过程，这是配置Servlet的最好机会。我们可以在这个阶段干些啥事情呢？ 1、把初始化的那些init-param读到Servlet的属性里。我们知道Servlet的init-param是放在ServletConfig里的，我们可以用循环去取这些属性。但是每次都这么干实在太累了，干吗不把在Servlet里增加几个property，再这些init-param直放到Servlet的property里呢？呵呵，以后那些初始参数都可以直接拿来用啦，真方便。DispatchServlet的一个祖先类叫做HttpServletBean就是专门干这个的。以后假如我们要写自己的Servlet也可以直接继承HttpServletBean这个类，这样读ServletConfig的操作都省掉了，哈哈！ 2、从ServletContext里取出ApplicationContext，并扩展成自己的ApplicationContext. 在ApplicationContext之谜里我们已经提到我们可以用Servlet Listner执行的机会把ApplicationContext放到ServletContext中去。但是不是直接拿这个ApplicationContext就足够了呢？no。我们先问一个简单的问题吧：在Spring MVC里我们是不是只能配置一个Servlet呢？Struts就是那么干的，所以在Struts里所有的request过来都会交给一个Servlet去处理。但是在Spring MVC里，我们却可以有好多个Servlet！它们可以处理不同类型的request，而且更重要的是它们的ApplicationContext不是相同的，它们共享了一个父ApplicationContext，也就是从ServletContext里取出来的那个，但是它们却会根据自己的配置作扩展，形成这个Servlet特有的ApplicationContext。这个子的ApplicationContext里有自己的namespace，也就是将一个叫做（假如servlet名称叫xiecc）?xiecc-servlet.xml的配置文件读进来，行成一个自己的ServletContext。所以这些过程全是在DispatchSevlet的一个父类FrameworkServlet里干的。 3、初始化接来要干的一件最重要的事情是初始DispatchServlet里的接口。如果用IOC容器的角度来说，其实是将ApplicationContext里定义好的接口注入到一个叫做DispatchServlet的bean里，只不过这个注入过程是手动的。注入的代码大致如果下（部分角色的含义和作用以后会解释）： initMultipartResolver(); initLocaleResolver(); initThemeResolver(); initHandlerMappings(); initHandlerAdapters(); initHandlerExceptionResolvers(); initViewResolvers(); 每个init方法其实是属性设置的过程，因为我们可以拿到自己的ApplicationContext，所以这一切都变得很轻松啦。比如说multipartResolver，直接用getWebApplicationC