我自己理解的MVC,MVP,MVVM

写下这篇文章,以后有人问我MVC的问题,我就发给他。语言短暂,文字长存

老生常谈的发一个这种基础概念文章,应该没什么人关注吧?

对了,这篇文章长期更新。

MVC模型

MVC解决的软件模型中只解决两类显性的任务:

  1. 修改数据。

    比如改动数据库中的数据,比如改变一个状态机中的状态(典型的未登录、登录中、已登录)

  2. 展现内容给用户。

​MVC根据这两类任务,区分了 View 和 Model 两个角色。简单来说 View 负责一切界面展现相关的事情,Model 负责所有修改数据的问题。

那为什么要Controller这个角色?

我从这么几个方面来考虑Controller的必要性。

  • View 不需要知道调用哪个Model。我们经常会改动支撑View 展示的Model。需要一个中间角色来接收 View 操作的消息,并且通知Model 产生变化的。

  • 根据程序运行在什么容器中,会有一些 View 的交互以外的用户操作需要造成Model 中的数据变化。典型的比如 WebApp 中的 Url 跳转导致的 hashChange事件;Android App 中由于用户点击了 Home键导致的 onPause 事件;

​所以针对这两个方面我理解了,除了 View 和 Model 显性的处理「两类基本任务」以外。需要Controller 充当这么一个角色:

Controller 的主要职责

  1. 管理界面消息和数据操作的映射关系,并充当两者间的转发者。(接受界面消息,调用数据操作)
  2. 接受程序运行所处容器的事件。(由于容器的变化也是由用户导致的,比如关机、刷新页面、手机home键,所以可以说Controller也是直接接受用户操作的)。

所以这幅带有User 角色的关系图我觉得更适合描述MVC模型的关系:
这里写图片描述

Android App 中的 MVC模型:

由于Android 开发经验比较多,先说说 Android 中的 MVC个个角色具体体现在什么东西上面:

  • View:从形态上来说有应用界面,弹窗界面,通知栏界面这些都是View。从实现上来说,layout,View,Button 这些都是View。
  • Controller:Activity,Service都是Controller。不过在实际开发过程中,我们不想让Activity和Service中的代码太重,所以会比如在Activity 以外新增 XXController 的类。由Activity接收界面消息和系统事件(都是用户操作引起的)。由XXController 来进行 Model的实际操作。
  • Model:Android 中Model 层的代码是比较重的,HTTP通信,数据本地存储,图片处理,算法计算等都得组织在这个包中。所以我们会在Model下根据功能类型做一些细分的设计模式。

Web App 中的 MVC 模型

我刚开始搞Web App 开发,不过对 MVC 在 Web App 的角色体现也有一些自己的想法:

  • View:这个很明确,就是浏览器的界面了,什么表单,列表,文本框,都是View。
  • Controller:在WebApp 中由于 View 在客户端 Model 在服务端。所以这个Controller分两半说,在前端的部分,接受dom和window的事件的部分就是Controller。再比如我用的Webx这个MVC的web框架,支持的velocity模板中,可以在表单中指定服务端响应表单的action类是什么,这也是controller角色的体现。而在服务端部分,典型的 Serlvet接受 Tomcat 等容器的消息,所以也是controller的一部分。
  • Model:这部分就是比如Servlet接收到请求后的数据处理部分了。

MVP 模型

​不管是MVP还是MVVM模型,都是MVC模型的一种演化形式。从本质上来说两个显性的任务不会变化:

  1. 修改数据。
  2. 展现内容给用户。

​MVP中关键是把 Controller 换成了 Presenter。Presenter 的中文含义就是主持人的意思。所以其实MVP的关键就是View 和 Model 不会 直接联系,所有调用都会通过 Presenter 来进行。

这还是我看了阮一峰大神的文章才有体会

​当然这种隔离关系不是需要开发者自己来刻意维护的。而是你使用的MVP框架的实现为开发者完成了隔离。遵循框架的规则就能实现隔离。

​所以MVC模型中,View 和Model 是有直接联系的咯?是这样的,由于MVC模型不强调VIew不能调用Model,所以开发者很容易实现View直接调用Model的逻辑。比如我们会直接在View 中创建一个监听数据变化的listener注册到Model中,这样在Model的数据变化时,View就是直接的改变。这样看起来很轻量化,但是实际上Model是常驻的,而View是暂时的,随着界面的销毁、刷新等,View需要手动注册和注销这个监听,这方面的管理也是非常麻烦的。

MVVM模型

​MVVM又是基于MVP的一种演化,关键在于 Presenter换成了 ViewModel。字面上看Model是进行数据的处理的,ViewModel就是界面层数据处理的。这样看没错。

​具体来说MVVM模型的关键,在于View的变化会直接体现在ViewModel中。当然这种直接体现,就是MVVM框架来实现的。这种变化的直接体现的好处,在于开发者开发View中的显示逻辑和VM中调用model的业务逻辑可以隔离的非常好,不需要在View中还去调用ViewModel。

MVC(Model-View-Controller)、MVP(Model-View-Presenter)和MVVM(Model-View-ViewModel)是常见的软件架构模式,用于组织和管理应用程序的代码。 1. MVC(Model-View-Controller): - Model(模型):负责存储和管理应用程序的数据和业务逻辑。 - View(视图):负责显示数据并与用户进行交互。 - Controller(控制器):处理用户输入,并根据输入更新模型和视图。 在MVC中,模型和视图是相互独立的,通过控制器来协调数据的更新和视图的更新。用户的输入首先由控制器处理,然后控制器更新模型的状态,最后模型的变化会反映在视图上。MVC模式可以有效地分离应用程序的逻辑和界面。 2. MVP(Model-View-Presenter): - Model(模型):负责存储和管理应用程序的数据和业务逻辑。 - View(视图):负责显示数据并与用户进行交互。 - Presenter(展示器):作为View和Model之间的中间人,处理用户输入并更新模型和视图。 在MVP中,Presenter负责处理用户的输入,并根据输入更新模型和视图。View只负责显示数据和将用户输入传递给Presenter,而不直接与模型交互。这种分离使得视图和模型可以独立开发和测试。 3. MVVM(Model-View-ViewModel): - Model(模型):负责存储和管理应用程序的数据和业务逻辑。 - View(视图):负责显示数据并与用户进行交互。 - ViewModel(视图模型):作为View和Model之间的中间人,处理视图的状态和行为,并将数据从模型转换为视图可用的形式。 在MVVM中,视图通过绑定(数据绑定)与视图模型关联,当模型的状态发生变化时,视图模型会自动更新视图。这种双向绑定使得视图和模型始终保持同步,减少了手动更新视图的代码量。 总结来说,MVCMVPMVVM都是用于组织和管理应用程序的代码,它们都有各自的优势和适用场景。选择哪种架构模式取决于应用程序的需求、团队的技术背景和个人偏好。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值