为什么要使用SpringMVC
为什么要使用springMVC?他的出现解决了什么问题？
首先回顾一下WebMVC:
如果没有MVC设计模式。程序间的各层之间依赖非常强，耦合度高。严重违背了高内聚低耦合的设计原则。而WebMVC将控制逻辑和功能处理，模型和视图进行了分离。降低耦合但是WebMVC也有严重的缺点：
- 控制器(controller）
1.控制逻辑较为复杂，而且每个模块都需要一个控制器，（可能每一个页面都需要一个控制器）
2.请求参数到模型的封装麻烦。
3.视图的选择严重依赖于Servlet API ，这样很能甚至不可能更换视图
4.给视图传入模型数据 也依赖于Servlet API.如果要更换视图那么技术也要改变。 - 模型(model)
使用JavaBean组件，（域模型层+业务层+持久层）导致JavaBean组件类庞大。不利于开发人员管理 - 视图(view)
被绑定于Jsp,很难更换视图
如何解决WebMVC的缺点
从服务到工作者模式：
服务到工作者：Front Controller + Application Controller + Page Controller + Context即，前端控制器+应用控制器+页面控制器（也有称其为动作）+上下文
前端控制器:
负责为表现层提供统一访问点，从而避免WebMVC中出现的重复的控制逻辑,可以为多个请求提供共用的逻辑（如准备上下文等等）,
将选择具体视图和具体的功能处理分离。
应用控制器:
前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响
页面控制器/动作/处理器：
功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。
上下文
WebMVC中为视图准备要展示的模型数据，我们直接放在request中（Servlet API相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如Servlet API）的访问/设置模型数据，一般通过ThreadLocal模式实现。
web设计遵循的原则
干净的web表现层：
模型和视图的分离；
控制器中的控制逻辑与功能处理分离（收集并封装参数到模型对象、业务对象调用）；
控制器中的视图选择与具体视图技术分离。
轻薄的web表现层：
做的事情越少越好，薄薄的，不应该包含无关代码；
只负责收集并组织参数到模型对象，启动业务对象的调用；
控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略；
尽量少使用框架特定API，保证容易测试。
而SpringMVC就是按照从服务到工作者的模式设计的。
深入理解看大牛博客:
http://jinnianshilongnian.iteye.com/blog/1593441
