【 MVC 、MVP、MVVM】模式浅谈

一、三层架构

其实这些模式,无论MVC、MVP、MVVM都是基于三层架构的

对于三层架构,就是整个系统,应该是分为三部分,即视图层,业务逻辑层,数据访问层

这里粘一下我写过的博客内容:

什么是三层架构:

所谓系统架构是指,整合应用系统程序大的结构。经常提到的系统结构有两种:三层架构与 MVC。这两种结构既有区别,又有联系。但这两种结构的使用,均是为了降低系统模块间的耦合度。

三层架构是指:视图层 View、服务层 Service,与持久层 DAO。它们分别完成不同的功能。

  • View 层:用于接收用户提交请求的代码
  • Service 层:系统的业务逻辑主要在这里完成
  • DAO 层:直接操作数据库的代码

为了更好的降低各层间的耦合度,在三层架构程序设计中,采用面向抽象编程。即上层对下层的调用,是通过接口实现的。而下层对上层的真正服务提供者,是下层接口的实现类。服务标准(接口)是相同的,服务提供者(实现类)可以更换。这就实现了层间解耦合。

在这里插入图片描述
通俗的理解图解是:
在这里插入图片描述
1、 规则

  1. 最关键的,UI层只能作为一个外壳,不能包含任何业务逻辑的处理过程。只有少量(或者没有)SQL语句或者存储过程的调用,并且这些语句保证不会修改数据。
  2. 设计时应该从业务逻辑出发,而不是UI出发。业务逻辑层在API上应该实现所有业务逻辑(以面向对象的方式)。如果把UILayer拿掉,项目还能在Interface/API的层次上提供所有功能)。
  3. 不管数据层是一个简单的SqlHelper也好,还是带有Mapping过的Classes也好,应该在一定的抽象程度上做到系统无关(DAO层可以移植到其他类似环境的项目)。
  4. 不管使用COM+(Enterprise Service),还是Remoting,还是WebService之类的远程对象技术,不管部署的时候是不是真的分别部署到不同的服务器上,最起码在设计的时候要做这样的考虑,更远的,还得考虑多台服务器通过负载均衡作集群(三个模块,可以分别运行于不同的服务器)。

2、 优势

  1. 结构清晰、耦合度低,

  2. 可维护性高,可扩展性高;

  3. 利于开发任务同步进行;容易适应需求变化

3、 劣势

  1. 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码

  2. 增加了代码量,增加了工作量,增加了复杂度。

二、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 处理后,将处理结果再交给 Controller
  • Controller 在接到处理结果后,根据处理结果找到要作为向客户端发回的响应 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的这个模型是不会变得。

模型结构如下:
在这里插入图片描述

  1. MVP适用于基于事件驱动的应用框架中,如Asp.net Web Forms 和Windows Forms应用。
  2. MVP中严格禁止View和Model间的直接交互,必需通过Presenter来完成。Model的独立性得到了真正的体现,它不仅仅与可视化元素的呈现(View)无关,与UI处理逻辑也无关。使用MVP的应用是用户驱动而不是Model驱动,所以Model不需要主动通知view。
  3. 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 模板

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值