---恢复内容开始---
当当当!!沉寂两日,学习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
Backbone.js Is Not An MVC Framework