---恢复内容开始---
当当当！！沉寂两日，学习Spring Web MVC去了。吐槽：近日跟同行探讨了下，前端攻城师，左肩担着设计师绘图，右肩担着JAVA代码？！我虽设计过UI，但这只算是PS技巧+偶尔的灵感，真正的设计师是讲创意、实用和美学的吧！呃，认为只有高手才懂得JAVA~~现在要努力做前端中设计好的，设计中懂得JAVA的？不错的方向吧,嘿嘿^^只要付出肯定有点收获！好吧，瑾以此文表达我的积极向上，我还在路上！如果Spring以后用不到，我就用又学到东西，阿Q自勉了- -!
一、为什么使用MVC
1 数据层代码和像HTML这样的表示层代码分开，易于定位问题和修改
2 数据层和表现层分开，可以实现多个视图共享一个模型的架构。起到重用数据层的作用
3 结构清晰，有利于分工协作
4 同设计模式一样，也是代码分离的一种手段，让冗长的代码，结构化
二、什么是MVC ( Wikipedia):
MVC开始是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
Model（模型）：数据模型，提供要展示的数据，因此包含数据和行为，可以认为是领域模型或JavaBean组件（包含数据和行为），不过现在一般都分离开来：Value
Object（数据） 和
服务层（行为）。也就是模型提供了模型数据查询和模型数据的状态更新等功能，包括数据和业务。
View（视图）：负责进行模型的展示，一般就是我们见到的用户界面，客户想看到的东西。
Controller（控制器）：接收用户请求，委托给Model进行处理（状态改变），处理完毕后把返回的模型数据返回给View，由视图负责展示。
也就是说控制器做了个调度员的工作。
从上图我们还看到，在标准的MVC中模型能主动推数据给视图进行更新。Model模型包含被用于填充View视图的数据。一个用户发起请求，Controller控制器处理请求，更新Model模型。这些Model模型，被反馈到View。它是一个循环。
三、从Backbone来理解MVC，有时候被称作MVP(LessThanDot.com)
注意到没，Model和View之间是不能传递任何信息的！这个最核心的是Presenter,在MVP的Presenter是负责从模型取数据，综合之后把它推送到View中。当一个View上有行为的时候，Presenter拦截它并与其他服务协调工作，导致Model变化。Presenter把这些Model的变化，推动他们回到了到视图。比喻为电梯，向上移动Model数据，向下更改View结构。
ok，这MVC、MVP只是个称呼，大家还都是称呼MVC。
一个常见的Web APP流程：
1. 用户在View上进行操作——比如在文本框输入数值或是点击按钮
2.
Controller处理这个动作
3. Controller通过Model对数据进行增删改查，将其传递到View
4.
View将数据展示给用户
从前端的角度来理解~~
那么View如何对Controller发送信息？有三种方式
1、目标操作(target-cation)：工作方式：Controller在自己内部设定目标target,分发一个操作action给View对象，比如是个按钮。当按钮被点击时，action就会发送给与之对应的target。这样V和C就交流了，但V只知道发送action给target,并不了解C中如何处理的。
2、委托(delegate):用户交互不仅仅是按钮、滑块之类。绝大部分的delegate信息都是should，will，did这三种形式。should-V视图对象询问C的某对象，“我应该做什么”。比如点击一个连接，V视图对象问“我要打开这个链接吗”，这个是should信息。will-“我将要做这件事",did-“我已经做了这件事”。C把自己设置为V的委托(delegate),它让V知道：如果V想知道更多的关于将如何显示的信息的话，就向C发送delegate信息。通过接受V发过来的delegate信息，C就会做出相应的协调和处理。还有一点，每个V只能有一个delegate。
3、数据源(datasource)：V不能拥有它所要显示的数据，记住这点非常重要！！V希望别人帮助它管理将要显示的数据，当它需要数据时，它就会请求别人的帮助,把需要的数据给它。datasource和delegate类似，V会发送cout，data、at信息给C来请求数据。
当Model发生变化了，如何告知Controller呢？
通知（Notification）是解决问题的好方法！它们是这样工作的，当M中的某些东西发生变化时，他们会向C发出通知“嘿，老兄，注意了啊，我这发生变化了”，或者他们会发出指向变化的指针给C，或其他什么的。
顺带推荐一个Backbone源码分析-Backbone架构+流程图 ！虽然这个系列没有完成，但是架构和流程图对Backbone的整体把握还是非常有帮助的！
大致就是这样工作的了！
第四、Web MVC
MVC下面这个图是不是更直观呢？
Web端开发发展历程
CGI：（Common Gateway Interface）公共网关接口，一种在web服务端使用的脚本技术，使用C或Perl语言编写，用于接收web用户请求并处理，最后动态产生响应给用户，但每次请求将产生一个进程，重量级。
Servlet：一种JavaEE web组件技术，是一种在服务器端执行的web组件，用于接收web用户请求并处理，最后动态产生响应给用户。但每次请求只产生一个线程（而且有线程池），轻量级。而且能利用许多JavaEE技术（如JDBC等）。本质就是在java代码里面 输出 html流。但表现逻辑、控制逻辑、业务逻辑调用混杂
JSP：（Java Server Page）：一种在服务器端执行的web组件，是一种运行在标准的HTML页面中嵌入脚本语言（现在只支持Java）的模板页面技术。本质就是在html代码中嵌入java代码。JSP最终还是会被编译为Servlet，只不过比纯Servlet开发页面更简单、方便。
直接转入最终模式~~
服务到工作者：Front Controller + Application Controller + Page Controller + Context
即，前端控制器+应用控制器+页面控制器（也有称其为动作）+上下文，也是Web MVC，责任更加明确。
这种清晰地结构让人一目了然，原作者非常厉害！
职责：
Front
Controller：前端控制器，负责为表现层提供统一访问点，从而避免Model2中出现的重复的控制逻辑（由前端控制器统一回调相应的功能方法，如前边的根据submitFlag=login转调login方法）；并且可以为多个请求提供共用的逻辑（如准备上下文等等），将选择具体视图和具体的功能处理（如login里边封装请求参数到模型，并调用业务逻辑对象）分离。
Application
Controller：应用控制器，前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响。
Page
Controller(Command)：页面控制器/动作/处理器：功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。
Context：上下文，还记得Model2中为视图准备要展示的模型数据吗，我们直接放在request中（Servlet
API相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如Servlet
API）的访问/设置模型数据，一般通过ThreadLocal模式实现。
文章列表
虽然博客中不允许涉及私塾在线，还是要感谢---跟开涛学SpringMVC