【 MVC 、MVP、MVVM】模式浅谈 | 您所在的位置:网站首页 › vue的mvc模型 › 【 MVC 、MVP、MVVM】模式浅谈 |
一、三层架构
其实这些模式,无论MVC、MVP、MVVM都是基于三层架构的 对于三层架构,就是整个系统,应该是分为三部分,即视图层,业务逻辑层,数据访问层 这里粘一下我写过的博客内容: 什么是三层架构: 所谓系统架构是指,整合应用系统程序大的结构。经常提到的系统结构有两种:三层架构与 MVC。这两种结构既有区别,又有联系。但这两种结构的使用,均是为了降低系统模块间的耦合度。 三层架构是指:视图层 View、服务层 Service,与持久层 DAO。它们分别完成不同的功能。 View 层:用于接收用户提交请求的代码Service 层:系统的业务逻辑主要在这里完成DAO 层:直接操作数据库的代码为了更好的降低各层间的耦合度,在三层架构程序设计中,采用面向抽象编程。即上层对下层的调用,是通过接口实现的。而下层对上层的真正服务提供者,是下层接口的实现类。服务标准(接口)是相同的,服务提供者(实现类)可以更换。这就实现了层间解耦合。 通俗的理解图解是: 1、 规则 最关键的,UI层只能作为一个外壳,不能包含任何业务逻辑的处理过程。只有少量(或者没有)SQL语句或者存储过程的调用,并且这些语句保证不会修改数据。设计时应该从业务逻辑出发,而不是UI出发。业务逻辑层在API上应该实现所有业务逻辑(以面向对象的方式)。如果把UILayer拿掉,项目还能在Interface/API的层次上提供所有功能)。不管数据层是一个简单的SqlHelper也好,还是带有Mapping过的Classes也好,应该在一定的抽象程度上做到系统无关(DAO层可以移植到其他类似环境的项目)。不管使用COM+(Enterprise Service),还是Remoting,还是WebService之类的远程对象技术,不管部署的时候是不是真的分别部署到不同的服务器上,最起码在设计的时候要做这样的考虑,更远的,还得考虑多台服务器通过负载均衡作集群(三个模块,可以分别运行于不同的服务器)。2、 优势 结构清晰、耦合度低, 可维护性高,可扩展性高; 利于开发任务同步进行;容易适应需求变化 3、 劣势 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码 增加了代码量,增加了工作量,增加了复杂度。 二、MVC:MVC,即 Model 模型、View 视图,及 Controller 控制器。 View:视图,为用户提供使用界面,与用户直接进行交互。View实现可视化界面的呈现并捕捉最终用户的交互操作。View可以直接调用Model查询其状态信息,而Model也可以在自己的状态发生改变时,主动通知 View。Model:模型,承载数据,并对用户提交请求进行计算的模块。其分为两类,一类称为数据承载 Bean,一类称为业务处理 Bean。所谓数据承载 Bean 是指实体类,专门用户承载业务数据的,如 Student、User 等。而业务处理 Bean 则是指 Service 或 Dao 对象, 专门用于处理用户提交请求的。Model对应应用状态和业务功能的封装,可以将它理解为同时包含数据和行为的领域模型(Domain Model)。Model接受Controller的请求并完成相应的业务处理,在应用状态改变的时候可以向View发出相应的通知。Controller:控制器,用于将用户请求转发给相应的 Model 进行处理,并根据 Model 的计算结果向用户提供相应响应。Contoller是M和V之间的连接器,用于控制应用程序的流程。View捕获用户交互操作后直接转发给Contoller,后者完成相应的UI逻辑。如果需要涉及业务功能的调用,Contoller会直接调用Model及修改Model状态。Contoller也可以主动控制原View或创建新的View对用户交互操作予以响应。MVC 架构程序的工作流程: 第一种模式:(可以理解为@responsebody返回json数据,json数据是由controller返回,view层刷新视图靠js刷新) 用户通过 View 页面向服务端提出请求,可以是表单请求、超链接请求、AJAX 请求等服务端 Controller 控制器接收到请求后对请求进行解析,找到相应的 Model 对用户请求进行处理 Model 处理后,将处理结果再交给 ControllerController 在接到处理结果后,根据处理结果找到要作为向客户端发回的响应 View 页面。页面经渲染(数据填充)后,再发送给客户端。第二种模式:(可以理解为在controller中形参为Model,对Model进行操作,controller返回Model需要渲染的页面) 用户通过 View 页面向服务端controller提出请求,可以是表单请求、超链接请求、AJAX 请求等服务端 Controller 控制器接收到请求后对请求进行解析,找到相应的 Model 对用户请求进行处理 , 处理后,将处理结果信息放入Model中。Controller 在信息放入Model中后,根据处理结果找到要作为向客户端发回的响应 View 页面。页面经渲染(数据与Model中的对应属性绑定)后,再发送给客户端。这种模式中View会直接从Model中读取数据而不是通过 Controller。 综上:三层架构+MVC是对一种情况的两种角度的看法,他们之间关系如下: 更加准确地描述MVC: 如果说ORM(Object Relation Mapping)等框架是数据访问层的框架模式,解除了业务逻辑和数据之间的耦合,业务逻辑不再关心底层数据如何存储和读取。所有数据呈现给业务逻辑层的就是一个个的对象。MVC则是表现层的框架模式。用于解除业务逻辑和视图之间的耦合。从而易于扩展,便于测试。 注:对于model的误解: 把Model理解成实体类(Entity) 在MVC中Model应该包含2部分功能,一部分是处理业务逻辑,一部分是提供View显示的数据。 它应该是业务逻辑真正的实现层。所以Model的实际上是Business Model(业务模型)。而Controller仅仅起一个“桥梁”作用,它负责把View的请求转发给Model,再负责把Model处理结束的消息通知View。Controller的存在是为了使UI界面、UI逻辑、业务逻辑之间分离。 三、MVP(MVC变体):对于MVP模式,网上争论不一,我看有好多博客,写的是其中的V指的是 iView(视图接口),而有的博客,包括百度百科在内,都说这里的V,指的是 View(视图),总之,不管怎样,他们只是名字不同,MVP的这个模型是不会变得。 模型结构如下: MVP适用于基于事件驱动的应用框架中,如Asp.net Web Forms 和Windows Forms应用。MVP中严格禁止View和Model间的直接交互,必需通过Presenter来完成。Model的独立性得到了真正的体现,它不仅仅与可视化元素的呈现(View)无关,与UI处理逻辑也无关。使用MVP的应用是用户驱动而不是Model驱动,所以Model不需要主动通知view。MVP模式中的IView代表的是一个接口,一个将UI界面提炼而抽象出来的接口。接口意味着任何实现了该接口的界面,都能够复用已有的Presenter和Model代码。是真正意义上的隔离View的细节和复杂性的模式,降低了Presenter对View的依赖。带来的好处就是定义在Presenter中的UI处理逻辑变得易于测试。总的来说,MVP模式,将view层的作用将至最低,可以缓解view层过分复杂的问题,核心就是presenter,view只提供事件触发,将数据发送到presenter的功能,presenter执行controller的功能,来调用Model,Model返回的数据由presenter放到接口处,其实这就已经完成了数据的移交,view层只是继承了iView,或者说是实现了iView中的抽象方法。(个人理解,可能不对) MVP中Presenter与Model的交互很清晰,仅体现为Presenter对Model的单向调用。而View与Presenter直接的交互方式就成了MVP的核心。 四、MVVM【Model–View–ViewModel】 :对于MVVM模式,可以参考微信小程序,其实微信小程序的双向绑定,就是MVVM模式的体现,而小程序的思想,或者说Vue的思想,就是基于MVVM的。 MVVM 的核心是 ViewModel 层,它就像是一个中转站(value converter),负责转换 Model 中的数据对象来让数据变得更容易管理和使用,该层向上与视图层进行双向数据绑定,向下与 Model 层通过接口请求进行数据交互,起呈上启下作用。 MVVM模式中,一个ViewModel和一个View匹配,它没有MVP中的IView接口,而是完全的和View绑定,所有View中的修改变化,都会自动更新到ViewModel中(双向绑定),同时ViewModel的任何变化也会自动同步到View上显示。 在MVP中,接口IView, 解决对于界面UI的耦合; 而MVVM则干脆直接使用ViewModel和UI无缝结合, ViewModel直接就能代表UI。但是MVVM做到这点是要依赖具体的平台和技术实现。 这也就是为什么ViewModel不需要实现接口的原因,因为对于具体平台和技术的依赖,本质上使用MVVM模式就是不能替换UI的使用平台的。 MVVM主要是用于分离应用界面层和业务逻辑层。 在MVC和MVP模式中, 开发View层的是程序员, 虽然UI/UE团队会做很多工作, 但这个层的"实现者"仍然是程序员。开发中将View层的代码逻辑抽取出来,并使View层很纯粹以便完全让美工去打造它。相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里。 这就相当于微信小程序里面的page.js,每页都有自己的page对象,与页面的布局分离。 微信小程序中的MVVM: Web应用中的MVVM模型: 参考博客: 前后端分手大师——MVVM 模式 三层架构、MVC、MVP、MVVM 浅谈MVC、MVP、MVVM架构模式的区别和联系 MVP模式 微信开放文档:WXML 模板 |
CopyRight 2018-2019 实验室设备网 版权所有 |