作为企业级 Java 开发者，可能开发过一些依据 Web 的使用程序，关于许多 Java 开发人员来说，依据 Web 的使用程序是他们首要的关注点。
如果有这方面阅历的话，能意识到这种体系所面对的应战，详细来讲，状况办理、作业流以及验证都是需求处理的重要特性。HTTP 协议的无状况性决议了这些问题都不那么简单处理。
Spring的 Web 结构就是为了处理这些关注点而规划的。Spring MVC 依据模型—视图—控制器（Model-View-Controller，MVC）形式完结，它能够构建像 Spring 结构那样灵敏和松耦合的 Web 使用程序。
SpringMVC 起步
你见到过孩子们的捕鼠器游戏吗？这是一个张狂的游戏，它的方针是发送一个小钢球，让它通过一系列八怪七喇的设备，终究触发捕鼠器。
小钢球穿过各种杂乱的配件，从一个斜坡上滚下来，被跷跷板弹起，绕过一个微型摩天轮，然后被橡胶靴从桶中踢出去。通过这些后，小钢球会对那只不幸又无辜的橡胶老鼠进行捕获。
乍看上去，Spring MVC 结构与捕鼠器有些相似。Spring 将恳求在调度 Servlet、处理器映射（handler mapping）、控制器以及视图解析器（view resolver）之间移动，而捕鼠器中的钢球则会在各种斜坡、跷跷板以及摩天轮之间翻滚。
可是，不要将 Spring MVC 与 Rube Goldberg-esque 捕鼠器游戏做过多比较。每一个 Spring MVC 中的组件都有特定的意图，而且它也没有那么杂乱。
让我们看一下恳求是怎么从客户端建议，通过 Spring MVC 中的组件，终究再回来到客户端。
盯梢 Spring MVC 的恳求
每逢用户在 Web 浏览器中单击链接或提交表单的时分，恳求就开端作业了，对恳求的作业描绘就像是快递投送员。
与邮局投递员或 FedEx 投送员一样，恳求会将信息从一个当地带到另一个当地。
恳求是一个非常繁忙的家伙，从脱离浏览器开端到获取呼应回来，它会阅历许多站，在每站都会留下一些信息一起也会带上其他信息。下图展现了恳求运用 Spring MVC 所阅历的一切站点。
在恳求脱离浏览器时，会带有用户所恳求内容的信息，至少会包括恳求的 URL。可是还可能带有其他的信息，例如用户提交的表单信息。
恳求旅程的第一站是 Spring 的 DispatcherServlet，与大多数依据 Java 的 Web 结构一样，SpringMVC 一切的恳求都会通过一个前端控制器（front controller）Servlet。
前端控制器是常用的 Web 使用程序形式，在这里一个单实例的 Servlet 将恳求托付给使用程序的其他组件来履行实践的处理。在 SpringMVC 中，DispatcherServlet 就是前端控制器。
DispatcherServlet的使命是将恳求发送给 Spring MVC 控制器（controller），控制器是一个用于处理恳求的 Spring 组件。
在典型的使用程序中可能会有多个控制器，DispatcherServlet 需求知道应该将恳求发送给哪个控制器。
所以 DispatcherServlet 会查询一个或多个处理器映射（handler mapping）来断定恳求的下一站在哪里，处理器映射会依据恳求所带着的URL 信息来进行决议计划。
一旦挑选了适宜的控制器，DispatcherServlet 会将恳求发送给选中的控制器，到了控制器，恳求会卸下其负载（用户提交的信息）并耐性等候控制器处理这些信息。
实践上，规划杰出的控制器自身只处理很少乃至不处理作业，而是将事务逻辑托付给一个或多个效劳目标进行处理
控制器在完结逻辑处理后，一般会发生一些信息，这些信息需求回来给用户并在浏览器上显现，这些信息被称为模型（model）。
不过只是给用户回来原始的信息是不行的——这些信息需求以用户友爱的方法进行格式化，一般会是 HTML。所以，信息需求发送给一个视图（view），一般会是 JSP。
控制器所做的终究一件事就是将模型数据打包，而且标示出用于烘托输出的视图名，它接下来会将恳求连同模型和视图名发送回 DispatcherServlet。
这样，控制器就不会与特定的视图相耦合，传递给 DispatcherServlet 的视图名并不直接表明某个特定的 JSP。实践上，它乃至并不能断定视图就是 JSP。
相反，它只是传递了一个逻辑称号，这个姓名将会用来查找发生成果的真实视图。
DispatcherServlet 将会运用视图解析器（view resolver）来将逻辑视图名匹配为一个特定的视图完结，它可能是也可能不是 JSP。
已然 DispatcherServlet 现已知道由哪个视图烘托成果，那恳求的使命根本上也就完结了。
它的终究一站是视图的完结（可能是 JSP），在这里它交给模型数据，恳求的使命就完结了。
视图将运用模型数据烘托输出，这个输出会通过呼应目标传递给客户端（不会像听上去那样硬编码）。
能够看到，恳求要通过许多的过程，终究才干构成回来给客户端的呼应。大多数的过程都是在 Spring 结构内部完结的，也就是上图所示的组件中。
在 web.xml 中声明 DispatcherServlet
在典型的 Spring MVC 使用中，我们会需求 DispatcherServlet 和 ContextLoaderListener。
AbstractAnnotationConfigDispatcherServlet-Initializer 会主动注册它们，可是如果需求在 web.xml 中注册的话，那就需求我们自己来完结这项使命了。
如下是一个根本的 web.xml 文件，它依照传统的方法搭建了 DispatcherServlet 和 ContextLoaderListener。

ContextLoaderListener 和 DispatcherServlet 各自都会加载一个 Spring 使用上下文。
上下文参数 contextConfigLocation 指定了一个 XML 文件的地址，这个文件界说了根使用上下文，它会被 ContextLoaderListener 加载。
如上图所示，根上下文会从“/WEB-INF/spring/root-context.xml”中加载 bean 界说。
DispatcherServlet 会依据 Servlet 的姓名找到一个文件，并依据该文件加载使用上下文。在上图中，Servlet 的姓名是 appServlet，因而 DispatcherServlet 会从“/WEB-INF/appServlet-context.xml”文件中加载其使用上下文。
如果期望指定 DispatcherServlet 装备文件的方位的话，那么能够在 Servlet 上指定一个 contextConfigLocation 初始化参数。
例如，如下的装备中，DispatcherServlet会从“/WEB-INF/spring/appServlet/servlet-context.xml”加载它的 bean：