Spring笔记 第五章： 构建Spring Web应用程序

大多数Java开发人员，做的都是与基于web的应用程序有关的工作。Spring 的 web框架就是为了解决这部分问题而设计的。

SpringMVC

网络请求就像是一个辛勤的快递员，需要经过诸多站点，才能到达目的地。让我们来看一下它究竟经过了多少“磨难”。

第一站：DispatcherServlet

DispatchServlet通常是单例的，它的任务主要是将请求发送给对应的控制器。所以DispatcherServlet需要查询处理器映射（handler mapping）来找到对应的控制器。

第二站：Controller
到达了控制器，请求会卸下自己所携带的信息（比如参数、请求头、请求体）将这些信息交付给控制器处理，自己则等待响应。设计良好的控制器往往本身不处理或仅处理很少部分的任务，主要逻辑将交给对应的service处理。

第三站：DispatcherServlet

Controller处理完成后，会产生一些信息（model），如果你只需要返回这些信息，那么便可以直接响应。如果你想要随之返回一些格式化模板和样式，那么控制器将会寻找该视图名，并将其与model一起返回给DispatcherServlet。

第四站：View Resolver
视图解析器根据视图名来匹配模板，并进行渲染，然后响应给客户端。

DispatcherServlet初始化

最早的时候，我们使用web.xml来配置servlet，在Servlet3规范之后（对应tomcat7及更高版本），这种方式已经渐渐被淘汰。在这个规范中，容器会在类路径中查找实现了某个指定接口（没有必要记忆具体是哪个，可以随用随查）的类，并用这些类来配置servlet。

Spring3.2引入了WebApplicationInitializer,它实现了上述说道的指定接口，因此容器会自动发现它，并用它来配置Servlet。

在DispatcherServlet在启动的时候，会创建两个上下文，一个包含了DispatcherServlet自身在初始化的时候，需要用到的bean；另一个则是由ContextLoaderListener创建的，它包含了其他初始化的bean（比如数据库的连接池等等）

其他

其他关于Controller、Repository、Service和 业务本身相关度比较高，框架层面上只要会使用一些api就是了，没有太多的东西，这里就不赘述了。