鸿蒙游戏为什么不能继续用传统 MVC？

子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、MVC 是为“页面”设计的二、游戏和管理系统根本不是一回事三、Controller 为什么一定会变胖四、Controller 的本质问题五、鸿蒙游戏真正需要的是什么六、Controller 管流程System 管规则七、状态驱动 VS 页面驱动八、多端场景下 MVC 更容易崩九、AI 时代进一步淘汰 Controller十、一个典型重构案例十一、MVC 最大的问题不是老十二、一个关键认知升级总结引言如果你做过传统客户端开发大概率接触过 MVCModel View Controller很多人第一次做鸿蒙游戏时也会下意识这样设计PlayerModel PlayerView PlayerController或者BattleModel BattleView BattleController刚开始项目很小的时候没问题 甚至感觉很规范但当游戏开始增加技能系统 任务系统 AI系统 多人同步 多端协同MVC 很快就会暴露出一个问题Controller 开始无限膨胀。最后你会看到BattleController 3000行或者GameController 5000行里面塞满了战斗逻辑 掉落逻辑 升级逻辑 AI逻辑 任务逻辑这时候问题已经不是代码风格了而是MVC 天生不适合承载复杂状态系统。一、MVC 是为“页面”设计的先理解一件事MVC 出现的时代桌面软件 管理系统 CRUD应用它解决的问题是用户操作界面 触发业务逻辑 更新界面例如点击按钮 ↓ Controller ↓ Model ↓ View更新这种模式非常适合表单 后台管理 办公软件因为状态变化少 逻辑链路短二、游戏和管理系统根本不是一回事游戏运行时用户输入 AI输入 时间事件 网络事件同时发生例如玩家攻击 怪物攻击 Buff生效 技能冷却 经验增长可能发生在同一时刻这时候如果全部进入Controller结果就是Controller成为总指挥三、Controller 为什么一定会变胖看一个典型例子classBattleController{attack(){player.attack()enemy.takeDamage()level.addExp()drop.dropItem()mission.update()}}刚开始几十行后来几百行最后上千行因为所有业务都会往 Controller 聚集。四、Controller 的本质问题MVC 中Controller 流程中心意味着所有逻辑都要经过它例如玩家升级Controller知道。任务完成Controller知道。Boss死亡Controller也知道。最后变成Controller知道整个世界这就是经典的God Controller上帝控制器五、鸿蒙游戏真正需要的是什么鸿蒙游戏更适合的模式是Store System UI因为天然分离状态 规则 展示例如传统 MVCView ↓ Controller ↓ ModelSystem 架构Input ↓ System ↓ Store ↓ UI看起来差别不大但本质完全不同。六、Controller 管流程System 管规则这是最核心的区别MVCController 负责决定做什么 负责决定怎么做 负责决定谁执行SystemBattleSystem 只管战斗 LevelSystem 只管升级 DropSystem 只管掉落每个系统只负责一个领域复杂度被自然拆散。七、状态驱动 VS 页面驱动MVC 本质页面驱动例如打开页面 ↓ Controller运行鸿蒙游戏本质状态驱动例如HP变化直接UI更新根本不需要Controller刷新页面这与 ArkUI 的设计天然一致。八、多端场景下 MVC 更容易崩鸿蒙最大的特点共存手机 平板 PC TVMVC 通常会变成PhoneController PadController PCController甚至不同View 不同Controller维护成本越来越高。System 架构则是Store ↓ System ↓ 多个UI例如手机UI 平板UI PC UI共享同一套规则九、AI 时代进一步淘汰 Controller过去驱动业务用户点击所以合理Controller但未来用户 AI Agent 自动任务 网络同步都在产生行为。这时候Controller已经无法承担统一入口。System 更适合UserInput AIInput NetworkInput统一进入System处理。十、一个典型重构案例很多项目最初是GameController负责战斗 升级 背包 任务 商城最后5000 行代码重构后BattleSystem LevelSystem MissionSystem InventorySystem ShopSystemController消失。只剩Engine负责调度。结果结构清晰 职责明确 扩展容易十一、MVC 最大的问题不是老很多人以为MVC 不好因为过时了。其实不是。MVC 到今天依然适合后台系统 管理平台 表单应用问题在于游戏已经不是页面系统。游戏更像持续运行的状态机而不是页面集合十二、一个关键认知升级初学者会觉得Controller控制游戏但真正的大型游戏架构会变成Store保存世界状态 System定义世界规则 UI展示世界结果Controller的重要性不断下降甚至最终消失。总结传统 MVCModel View Controller核心思想Controller驱动业务而鸿蒙游戏更适合Store System UI核心思想System驱动状态变化如果用一句话总结MVC 适合“页面驱动的软件”而鸿蒙游戏本质上是“状态驱动的世界”因此最终一定会从 Controller 走向 System。