标准 MVC 模型概述
MVC模型:是一种架构型的模式,本身不引入新功能,只是帮助我们将开发的结构组织的更加合理,使展示与模型分离、流程控制逻辑、业务逻辑调用与展示逻辑分离
- Model(模型):
数据模型,提供要展示的数据,因此包含数据和行为,可以认为是领域模型或 JavaBean 组件(包含数据和行为),不过现在一般都分离开来:Value Object(数据) 和 服务层(行为)。也就是模型提供了模型数据查询和模型数据的状态更新等功能,包括数据和业务。 - View(视图):
负责进行模型的展示,一般就是我们见到的用户界面,客户想看到的东西。 - Controller(控制器):
接收用户请求,委托给模型进行处理(状态改变) ,处理完毕后把返回的模型数据返回给视图,由视图负责展示。 也就是说控制器做了个调度员的工作。
在标准的 MVC 中模型能主动推数据给视图进行更新(观察者设计模式,在模型上注册视图,当模型更新时自动更新视图),但在 Web 开发中模型是无法主动推给视图(无法主动更新用户界面),因为在 Web 开发是
请求-响应模型。
Web MVC 概述
在 Web MVC 模式下,模型无法主动推数据给视图,如果用户想要视图更新,需要再发送一次请求(即请求-响应模型)。
在JavaEE世界里,它可以认为就是Web MVC模型
我们来看看以前的写法吧,这个是看大神写的,其实哈,我们学习过Struct2啦,看这个感觉就是有非常多的缺点的,所以我们还是的必须的看哈,才知道怎么去解决这些问题的!
可以看出,视图和模型分离了,控制逻辑和展示逻辑分离了!
之前的我刚开始学习jsp的时候也像这么的做过这些事情,简直是渣的不行啦~~那时候还觉得好厉害啊~ 我也是晕啦!
-
这些有啥子缺点呢~~
- 选择下一个视图,严重依赖 Servlet API,这样很难或基本不可能更换视图
- 给视图传输要展示的模型数据,使用 Servlet API,更换视图技术也要一起更换,很麻烦
-
此处模型使用 JavaBean, 可能造成 JavaBean 组件类很庞大, 一般现在项目都是采用三层架构, 而不采用 JavaBean。(这个就是我们说的Dao,Service…Entity)
-
现在被绑定在 JSP,很难更换视图,比如 Velocity、FreeMarker;比如我要支持 Excel、PDF 视图等等
- Front Controller + Application Controller + Page Controller + Context.即,前端控制器+应用控制器+页面控制器(也有称其为动作)+上下文,也是 Web MVC,只是责任更加明确
干净的 web 表现层:
模型和视图的分离;
控制器中的控制逻辑与功能处理分离(收集并封装参数到模型对象、业务对象调用) ;
控制器中的视图选择与具体视图技术分离。
轻薄的 web 表现层:
做的事情越少越好,薄薄的,不应该包含无关代码;
只负责收集并组织参数到模型对象,启动业务对象的调用;
控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略;
尽量少使用框架特定 API,保证容易测试
看到这个谢啦这么多的文字,确实很深入的理解啦~很不错哦
转载地址:http://blog.csdn.net/u012881904/article/details/51291387