web MVC简介
1、web开发中的请求响应模式
web的请求响应模式.png
如图，在web的世界里，大多都是Web客户端发起请求，Web服务器接收、处理并产生响应这种模式。（pull的概念）
一般Web服务器是不能主动通知Web客户端更新内容。虽然现在有些技术如服务器推，如：Comet（也称反向的ajax）、还有现在的HTML5 websocket可以实现Web服务器主动通知Web客户端。（push的概念）
2、标准MVC模型概述
MVC模型：是一种架构型的模式，本身不引入新功能，只是帮助我们将开发的结构组织的更加合理，是展示与模型分离，流程控制逻辑、业务逻辑调用与展示逻辑分离。
标准MVC模型.png
3、web MVC概述
web MVC模型.png
在Web MVC模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。
web端开发发展历程
web端发展历程.png
CGI：(Common Gateway Interface)公共网关接口，一种在web服务端使用的脚本技术，使用C或Perl语言编写，用于接收web用户请求并处理，最后动态产生响应给用户，但每次请求将产生一个进程，重量级。
Servlet：一中JavaEE web组件技术，是一种在服务器端执行的web组件，用户接收用户请求并处理，最后动态产生响应给用户，但每次请求只产生一个线程（而且有线程池），轻量级。而且能利用许多JavaEE技术（如JDBC等）。本质就是在java代码里面输出html流。但表现逻辑、控制逻辑、业务逻辑调用混杂。
JSP：(Java Server Page)，一中在服务器端执行的web组件，是一种运行在标准的HTML页面中嵌入脚本语言（现只支持Java）的模板页面技术。本质就是在html代码中嵌入java代码。JSP最终还是会被编译为Servlet，只不过比纯Servlet开发页面更简单、方便。但表现逻辑、控制逻辑、业务逻辑调用还是混杂。
Model1：可以认为是JSP的增强版，其实就是jsp+javabean的模式。
特点：使用<jsp:useBean>标准动作，自动将请求参数封装为JavaBean组件；还必须使用java脚本执行控制逻辑（用<% %>将Java代码包裹住）。
model1模式.png
Model1架构中，JSP负责控制逻辑、表现逻辑、业务对象（javabean）的调用，只是比纯JSP简化了获取请求参数和封装请求参数。
Model2：在JavaEE的世界里，可以认为就是Web MVC模型
Model2架构其实可以认为就是我们所说的Web MVC模型，只是控制器采用Servlet、模型采用JavaBean、视图采用JSP。
model2模型.png
当然，此处模型使用Javabean，可能造成Javabean的组件很庞大，一般现在都是使用三层架构，而不是使用javabean。
三层架构.png
从Model2架构可以看出，视图和模型分离了，控制逻辑和展示逻辑分离了。然而，
- 控制逻辑可能比较复杂，其实我们可以按照规约，如请求参数submitFlag=toAdd，我们其实可以直接调用toAdd方法，来简化控制逻辑；而且每个模块基本需要一个控制器，造成控制逻辑可能很复杂
- 请求参数到模型的封装比较麻烦，如果能交给框架来做这件事情，我们可以从中得到解放
- 选择下一个视图，严重依赖Servlet API，这样很难或基本不可能更换视图。给视图传输要展示的模型数据，使用Servlet API，更换视图技术也要一起更换，很麻烦
服务到工作者(Front Controller + Application Controller + Page Controller + Context) :即前端控制器 + 应用控制器 + 页面控制器（动作） + 上下文，也是web MVC，只是责任更加明确。
web MVC流程图.png
- Front Controller：前端控制器，负责为表现层提供统一访问点，从而避免Model2中出现的重复的控制逻辑（由前端控制器统一回调相应的功能方法，如前边的根据submitFlag=login转调login方法）；并且可以为多个请求提供共用的逻辑（如准备上下文等等），将选择具体视图和具体的功能处理（如login里边封装请求参数到模型，并调用业务逻辑对象）分离。
- Application Controller：应用控制器，前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响。
- Page Controller：页面控制器/动作/处理器：功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。
- context：上下文，还记得Model2中为视图准备要展示的模型数据吗，我们直接放在request中（Servlet API相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如Servlet API）的访问/设置模型数据，一般通过ThreadLocal模式实现。
综上，整个web开发框架的发展历程，最终需要达到的目的如下：
- 干净、轻薄的web表现层
- 模型和视图进行分离
- 控制器中的控制逻辑和功能处理逻辑分离，且控制逻辑可以统一化
- 视图选择和具体的视图实现技术分离，以达到可以轻易切换视图技术的目的
- 控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略
- 每个模块做的事情越少越好，薄薄的，降低耦合度
