从MVC到MVVM的意义之我见

本文探讨了MVC架构的基本原理及其在前端应用中的作用,并对比了MVVM架构的优势,尤其是在状态管理和数据流方面的改进。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

题外话:发现自己的草稿箱里面还有几篇很久以前写了一半但是忘了结尾的东西,年关将至把最不烧脑的一篇打扫一下发出来吧。

MVC

先来看一张MDN的官方图:

MVC MDN

我之所以班门弄斧自己整一张主要是为了接下来与MVVM的比较。
mvc myself

关于MVC的文章汗牛充栋,我就说一句个人认为理解的关键:单向数据流,状态管理方法论Flux是对它的极大改进。

从上图可以看出对于比较简单的应用,View, Controller, Model的分层是很清晰明了的,但是如果应用比较复杂,VIew与Model之间,Controller与Model之间很有可能是多对多的关系,作为一团乱麻会给应用的状态管理造成很大的混乱。

那么就有人提出改进的方法,可不可以将Model的职能简化(瘦Model),单纯的作为一个数据层呢:
thin model

答案当然是可以!!

那么最后形成的数据流就是现在大热的MVVM。

MVVM

MVVM

MVVM的意义不仅在于使应用程序的层次更加简单,状态更加清晰,更重要的是View和ViewModel的交互方式,衍生出了很多双向绑定的方法(Angular.js的脏检查,Vue的数据劫持)

备注:上文提到的MVC/MVVM都是基于前端的架构角度,记得以前看过一篇文章是从应用程序前后端的角度来阐述MVC/MVVM,文章找不到了但是我觉得很有意思,所以也记下来。

如果把应用程序作为一个前后端的整体,其实就是一种MVVM的模式。前端页面没有办法去直接操作后台数据库,只能通过发送http请求(像是flux/redux中精炼的action)到Server端,Server端收到请求后更新数据库,返回数据更新前端页面。

前端页面MVC的状态管理难搞就是因为view和model的之间的操作可以实现而且成本很低。

这个观点很有启发性。画一张图以表敬意 :)
mvvm

### Unity 中 MVCMVVM 的区别与适用场景 #### 一、MVC 架构模式概述 MVC 是一种经典的设计模式,分为三个主要部分:Model(模型)、View(视图)和 Controller(控制器)。 - **Model** 负责管理应用程序的数据以及业务逻辑。它独立于 UI 层,专注于数据的操作和存储[^4]。 - **View** 表示用户界面层,用于向用户显示信息并接收用户的输入。 - **Controller** 则作为中间件,在 View 和 Model 之间传递请求和响应。它是整个系统的协调者,负责解析用户操作并将这些操作转化为对 Model 或 View 的具体修改[^1]。 在 Unity 中实现 MVC 模式时,通常会通过脚本组件来分别定义这三个角色的功能。例如,`PlayerController.cs` 可能是一个典型的控制器类,用来监听玩家的按键输入,并通知 `PlayerModel.cs` 更新游戏角色的状态[^5]。 --- #### 二、MVVM 架构模式概述 MVVM(Model-View-ViewModel)是一种更现代化的架构模式,特别适合支持双向数据绑定的应用程序开发环境,比如 WPF 和 Xamarin[^3]。尽管如此,MVVM 同样可以应用于 Unity 开发中: - **Model** 部分仍然保持不变,继续承担数据管理和业务逻辑的任务。 - **View** 主要关注图形化表现形式,不直接依赖任何后台逻辑。 - 新增了一个名为 ViewModel 的层次,充当桥梁作用,使得 View 不再需要直接访问 Model 数据源即可完成交互需求。这种机制允许开发者利用属性更改通知功能自动同步界面上的变化到对应的对象实例上或者反之亦然。 相比起传统的 MVC 方法论来说,MVVM 更加强调减少代码量的同时提高可维护性和扩展能力;但由于缺乏内置的支持工具链(如 .NET 提供的相关特性),因此实际运用过程中可能还需要额外编写一些辅助函数才能达到理想效果[^2]。 --- #### 三、两者的主要差异对比 | 特性 | MVC | MVVM | |---------------------|-----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------| | **核心概念** | 控制器驱动型 | 绑定驱动型 | | **职责划分** | 明确区分了控制流路径 | 增加了一层抽象 (ViewModel),简化了视图逻辑 | | **复杂度** | 较低 | 对初学者而言稍显复杂 | | **灵活性/重用率** | 改变任何一个模块都可能导致其他两个模块也需要调整 | 修改任意一方几乎不会影响另外两方 | | **性能开销** | 几乎无明显增加 | 如果频繁触发大量数据更新,则可能会带来一定负担 | 值得注意的是,在某些情况下,为了弥补原生 API 功能上的不足之处,我们往往不得不手动模拟出类似的效果——这无疑增加了工作难度同时也降低了效率。 --- #### 四、适用场景分析 ##### (1)何时选用 MVC? 当项目规模较小且不需要复杂的动态行为时,采用 MVC 就已经足够满足大部分需求了。它的优势在于简单直观易懂,非常适合快速原型制作阶段或是团队成员技术水平参差不齐的情况下使用。 ```csharp // 示例代码片段展示了如何在一个简单的游戏里应用 MVC 设计思路 public class PlayerController : MonoBehaviour { private PlayerModel _model; void Start() { _model = new PlayerModel(); } void Update() { if (Input.GetKeyDown(KeyCode.Space)) { _model.Jump(); // 调用模型的方法改变状态 } } } ``` ##### (2)为何考虑 MVVM? 对于那些追求极致用户体验并且希望充分利用平台特性的大型跨平台移动应用来讲,MVVM 往往能够发挥更大价值。尤其是在涉及到多线程异步加载资源或者是实时渲染动画特效之类高并发计算密集型任务的时候尤为突出。 然而需要注意的是,由于 Unity 并未像桌面端那样天然具备强大的 XAML/Databinding Frameworks 支撑体系结构,所以要想真正意义上做到无缝衔接的话还是存在不少挑战待克服。 --- #### 五、总结 综上所述,虽然两种方式各有千秋,但在选择之前务必要充分权衡当前项目的实际情况后再做决定。如果只是单纯想构建一个小而美的休闲小游戏那么毫无疑问应该优先推荐大家尝试一下轻量化易于掌握的 MVC 方案;但如果目标定位更高远一点比如说打造一款次世代级别的 AAA 大作则不妨大胆探索下更加先进的技术路线即引入 MVVM 来优化整体工程品质[^1]. ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值