企业官网建设流程全解析

1. 为什么Unity项目需要MVC模式

1.1 从一次项目失控说起

前两年我接手过一个二次元卡牌手游的客户端重构，项目最初是三个人搭的Demo，后来功能越堆越多，战斗、背包、任务、抽卡、公会全塞在几十个MonoBehaviour里。最夸张的一个脚本叫GameManager.cs，四千多行，UI刷新、数据计算、网络回调、动画播放全混在一起。每次策划改一个数值规则，程序要翻半天代码才能定位到改哪一行；美术换一张图，经常牵一发动全身，改完A界面B界面崩了。这种场景我相信做过中大型Unity项目的朋友都不陌生。

后来我们花了两个月做架构梳理，核心动作就是引入MVC模式，把数据、界面、逻辑三层拆开。重构完之后，同样的需求改动量平均下降了六成，新人上手时间从两周缩短到三天。这不是什么玄学，就是职责分离带来的直接收益。

1.2 MVC到底解决什么问题

MVC是Model-View-Controller的缩写，翻译过来就是模型、视图、控制器。它最早是桌面GUI领域的经典架构，后来被广泛移植到游戏开发里。核心思想特别朴素：把"数据是什么"、"界面长什么样"、"用户操作怎么响应"这三件事分给三个角色去管，谁也别越界。

在Unity语境下，这三层通常这样对应：

很多人会问，Unity本身有组件化思想，为什么还要套一层MVC？我的理解是，组件化解决的是"功能复用"问题，MVC解决的是"职责边界"问题。一个按钮的点击音效可以用组件复用，但"点击后扣钻石、刷新钻石文本、播放动画、发网络请求"这一串流程，如果没有MVC约束，很容易写成意大利面条。

1.3 适合哪些项目引入

不是所有Unity项目都值得上MVC。我个人的判断标准是这样的：

• 适合：中大型项目、UI界面超过20个、有明确的数据驱动需求、团队超过3人、需要长期迭代维护。
• 不太适合：GameJam小Demo、纯展示类项目、生命周期只有几周的短平快需求。

强行给一个小项目套MVC，反而会增加样板代码量，得不偿失。这一点我在后面会专门讲怎么权衡。

2. MVC三层在Unity中的落地设计

2.1 Model层：纯数据与业务规则

Model层的核心原则是不依赖Unity引擎。也就是说，你的Model类不应该继承MonoBehaviour，不应该引用UnityEngine命名空间，最好连Vector3这种结构体都慎用（除非你确定逻辑层需要）。这样做的好处是Model可以被单元测试覆盖，可以脱离引擎运行，逻辑验证成本极低。

一个典型的Model长这样：

public class PlayerData { public int Level { get; private set; } public int Exp { get; private set; } public int Diamond { get; private set; } public event Action<int> OnLevelChanged; public event Action<int> OnDiamondChanged; public void AddExp(int value) { Exp += value; while (Exp >= GetLevelUpCost()) { Exp -= GetLevelUpCost(); Level++; OnLevelChanged?.Invoke(Level); } } public bool TryCostDiamond(int value) { if (Diamond < value) return false; Diamond -= value; OnDiamondChanged?.Invoke(Diamond); return true; } private int GetLevelUpCost() => 100 + Level * 50; }

注意这里用了事件（event）来通知外部数据变化，而不是直接去调用View。这是MVC里非常关键的一环：Model不知道View的存在，它只负责广播"我变了"，谁关心谁去订阅。这种解耦让Model可以独立测试，也让View可以随时替换。

提示：Model里的事件记得在对象销毁时取消订阅，否则容易造成内存泄漏。我见过不少项目因为Model持有View的委托引用，导致界面关了但对象回收不掉。

2.2 View层：只做显示，不做决策

View层的职责边界要卡死：只负责把数据渲染出来，只负责把用户操作转发出去，绝不自己做业务判断。很多新手容易在View里写if (diamond >= 100) { 扣钱; 刷新; }，这就越界了，判断逻辑应该属于Controller或Model。

一个规范的View示例：

public class ShopView : MonoBehaviour { [SerializeField] private Text diamondText; [SerializeField] private Button buyButton; [SerializeField] private Text buyButtonLabel; public event Action OnBuyClicked; private void Awake() { buyButton.onClick.AddListener(() => OnBuyClicked?.Invoke()); } public void RefreshDiamond(int value) { diamondText.text = value.ToString(); } public void SetBuyButtonState(bool interactable, string label) { buyButton.interactable = interactable; buyButtonLabel.text = label; } }

View通过[SerializeField]把UI引用拖好，通过事件把点击抛出去，通过公开方法接收刷新指令。它完全不知道钻石是怎么扣的，也不知道扣完会发生什么。这种"傻白甜"式的View，替换起来成本极低。

2.3 Controller层：粘合剂与调度中心

Controller是MVC里最灵活的一层，它负责把View的输入翻译成Model的操作，再把Model的变化翻译成View的刷新。在Unity里，Controller通常也挂在场景或预制体上，持有View和Model的引用。

public class ShopController : MonoBehaviour { [SerializeField] private ShopView view; private PlayerData model; private const int BuyCost = 100; public void Init(PlayerData data) { model = data; view.OnBuyClicked += HandleBuy; model.OnDiamondChanged += view.RefreshDiamond; RefreshAll(); } private void HandleBuy() { if (!model.TryCostDiamond(BuyCost)) { // 提示钻石不足 return; } // 后续发货逻辑 } private void RefreshAll() { view.RefreshDiamond(model.Diamond); view.SetBuyButtonState(model.Diamond >= BuyCost, $"购买({BuyCost})"); } private void OnDestroy() { if (model != null) model.OnDiamondChanged -= view.RefreshDiamond; view.OnBuyClicked -= HandleBuy; } }

Controller的Init方法很关键，它明确了依赖注入的入口。我习惯让Controller不自己去找Model，而是由上层（比如GameRoot或场景管理器）统一注入，这样依赖关系一目了然，也方便做Mock测试。

2.4 三层之间的通信规则

把通信规则定清楚，比写多少代码都重要。我总结了几条铁律：

1. View不能直接引用Model，只能通过事件把操作抛给Controller。
2. Model不能引用View和Controller，只能通过事件广播自身变化。
3. Controller可以引用View和Model，是唯一允许双向通信的角色。
4. 跨模块通信走事件总线或消息中心，不要让Controller之间互相持有引用。

这四条规则如果团队能守住，代码质量基本就有保障了。我见过太多项目败在"就这一次，我直接在View里读一下Model吧"，然后这一次变成无数次。

3. 完整实操：从零搭一个MVC商店模块

3.1 目录结构规划

动手之前先把目录定好，这一步很多人忽略，但后期维护全靠它。我推荐的目录结构：

Assets/ Scripts/ MVC/ Model/ PlayerData.cs ShopModel.cs View/ ShopView.cs ShopItemView.cs Controller/ ShopController.cs Core/ EventBus.cs MVCBinder.cs

Model、View、Controller分三个文件夹，Core放公共基础设施。这个结构简单直接，新人进来一眼就能找到对应文件。有些团队喜欢按功能模块分文件夹（比如Shop/Model、Shop/View），也完全可以，关键是团队内统一。

3.2 事件总线的实现

跨模块通信我一般用一个轻量级事件总线，避免Controller之间互相引用：

public static class EventBus { private static readonly Dictionary<Type, Delegate> events = new(); public static void Subscribe<T>(Action<T> callback) { var type = typeof(T); if (events.TryGetValue(type, out var d)) events[type] = Delegate.Combine(d, callback); else events[type] = callback; } public static void Unsubscribe<T>(Action<T> callback) { var type = typeof(T); if (events.TryGetValue(type, out var d)) { var result = Delegate.Remove(d, callback); if (result == null) events.Remove(type); else events[type] = result; } } public static void Publish<T>(T evt) { if (events.TryGetValue(typeof(T), out var d)) (d as Action<T>)?.Invoke(evt); } }

这个实现只有几十行，但足够应付大多数项目。注意Unsubscribe里对空委托的处理，否则容易残留空引用导致内存问题。

3.3 Model层实现细节

以商店模块为例，Model要管的是商品列表、购买记录、货币校验：

public class ShopModel { private readonly PlayerData player; private readonly List<ShopItem> items = new(); public IReadOnlyList<ShopItem> Items => items; public ShopModel(PlayerData player) { this.player = player; InitItems(); } private void InitItems() { items.Add(new ShopItem { Id = 1, Name = "体力药水", Price = 50 }); items.Add(new ShopItem { Id = 2, Name = "经验卡", Price = 100 }); items.Add(new ShopItem { Id = 3, Name = "稀有宝箱", Price = 500 }); } public bool TryBuy(int itemId) { var item = items.Find(i => i.Id == itemId); if (item == null) return false; if (!player.TryCostDiamond(item.Price)) return false; EventBus.Publish(new ItemBoughtEvent { ItemId = itemId }); return true; } }

Model里用IReadOnlyList暴露列表，防止外部直接修改。购买成功后发一个事件出去，谁关心谁订阅，比如背包模块、任务模块都可以监听这个事件。

3.4 View层与Controller层对接

View层我习惯做成一个通用列表项加一个容器：

public class ShopItemView : MonoBehaviour { [SerializeField] private Text nameText; [SerializeField] private Text priceText; [SerializeField] private Button buyButton; private int itemId; public event Action<int> OnBuyClicked; public void Bind(ShopItem item) { itemId = item.Id; nameText.text = item.Name; priceText.text = item.Price.ToString(); buyButton.onClick.RemoveAllListeners(); buyButton.onClick.AddListener(() => OnBuyClicked?.Invoke(itemId)); } }

Controller负责生成列表、绑定事件、处理购买结果：

public class ShopController : MonoBehaviour { [SerializeField] private Transform itemRoot; [SerializeField] private ShopItemView itemPrefab; [SerializeField] private Text diamondText; private ShopModel model; private PlayerData player; private readonly List<ShopItemView> views = new(); public void Init(PlayerData playerData) { player = playerData; model = new ShopModel(player); player.OnDiamondChanged += RefreshDiamond; BuildList(); RefreshDiamond(player.Diamond); } private void BuildList() { foreach (var item in model.Items) { var view = Instantiate(itemPrefab, itemRoot); view.Bind(item); view.OnBuyClicked += HandleBuy; views.Add(view); } } private void HandleBuy(int itemId) { bool success = model.TryBuy(itemId); if (!success) { // 弹出提示：钻石不足 } } private void RefreshDiamond(int value) { diamondText.text = value.ToString(); } private void OnDestroy() { if (player != null) player.OnDiamondChanged -= RefreshDiamond; foreach (var v in views) v.OnBuyClicked -= HandleBuy; } }

整个流程走下来，View不知道Model，Model不知道View，Controller在中间做调度。这就是MVC的标准形态。

3.5 参数与性能考量

有人担心事件订阅会带来性能开销。实测下来，一个界面几十个事件订阅，对帧率的影响可以忽略不计。真正需要注意的是事件订阅的时机和取消时机，如果忘记取消，对象回收不掉，内存会持续增长。

另外，列表项如果超过50个，建议上对象池，不要频繁Instantiate和Destroy。对象池和MVC不冲突，View层内部用池管理即可。

4. 常见问题与排查技巧实录

4.1 事件订阅泄漏怎么查

这是MVC项目里最高频的问题。表现是界面关了又开，同一个操作触发了两次甚至多次。排查方法很简单：在事件总线的Subscribe和Unsubscribe里打日志，统计每个事件类型的订阅数量，如果只增不减，就是泄漏了。

我一般会在开发期加一个调试面板，实时显示各事件的订阅数。上线前把这个面板关掉即可。

4.2 View和Controller职责模糊怎么办

判断标准就一条：如果这段代码脱离Unity也能跑，它就不该在View里。比如"判断钻石够不够"是纯逻辑，放Model或Controller；"把文本改成红色"是显示，放View。拿不准的时候，问自己"换一套UI，这段代码还要不要改"，要改的就是View的活。

4.3 Model更新后View没刷新

常见原因有三个：一是事件订阅写在了Awake里但Model还没初始化；二是订阅了但没取消，导致旧View还在响应；三是Model直接改了字段但没触发事件。我建议Model的所有状态变更都走方法，方法内部统一触发事件，不要暴露public字段。

4.4 常见问题速查表

4.5 我踩过的几个坑

第一个坑是在View的Awake里订阅Model事件。Awake执行顺序不确定，Model可能还没创建，结果订阅了个null。后来统一改成Init方法里订阅，由Controller控制时机。

第二个坑是Controller里直接new Model。这样Model无法复用，也无法注入测试数据。后来改成外部注入，Controller只负责使用不负责创建。

第三个坑是事件参数用object。早期图省事，EventBus用object传参，结果运行时各种类型转换错误。后来改成泛型，编译期就能发现问题。

5. MVC的变体与进阶实践

5.1 MVP与MVVM的取舍

MVC不是唯一解。UI特别重的项目，可以考虑MVP，把View抽象成接口，Presenter完全不知道具体UI实现，测试性更好。数据绑定需求强的项目，可以考虑MVVM，用响应式属性自动刷新界面，省去手动订阅。

我的经验是：中小项目MVC够用，大项目UI层可以往MVP靠，工具链成熟的话MVVM也很香。关键是别为了架构而架构，团队能驾驭才是第一位的。

5.2 与Unity组件化的融合

MVC和Unity的组件化不矛盾。我的做法是：MVC管逻辑分层，组件化管功能复用。比如一个"倒计时组件"可以挂在任何View上，它内部自己管自己的显示，对外只暴露StartCountdown和OnComplete，不参与MVC的分层。

5.3 大型项目的模块化拆分

项目大了之后，单个MVC三层会膨胀。这时候可以按功能模块拆，每个模块一套MVC，模块之间通过EventBus通信。比如商店模块、背包模块、任务模块各自独立，商店买完东西发事件，背包和任务各自响应。这样模块可以独立开发、独立测试，甚至独立热更。

5.4 代码生成与工具链

手写MVC样板代码很枯燥，我一般会写个编辑器工具，根据预制体结构自动生成View的字段绑定代码。Unity的UIBindComponent或者自己写个简单的代码生成器都行。这一步能省下大量重复劳动，也能减少手写字段名拼错的低级错误。

6. 一些实操心得

关于MVC在Unity里的落地，我个人最深的体会是：架构的价值不在于多优雅，而在于团队能不能长期守住边界。我见过架构设计得很漂亮但没人遵守的项目，也见过架构朴素但执行严格的项目，后者往往活得更久。

如果让我给刚接触MVC的朋友一条建议，那就是先从一个小模块开始试，比如设置界面或者背包界面，把三层跑通，感受一下职责分离带来的好处，再逐步推广到其他模块。一上来就全项目重构，风险太大，也容易半途而废。

另外，Model层的事件命名我习惯用过去式，比如OnLevelChanged、OnItemBought，表示"已经发生了变化"，而不是"即将变化"。这个小习惯能让代码可读性提升不少，团队协作时也不容易产生歧义。

最后分享一个小技巧：在Controller的Init方法里加一行日志，打印当前模块名和初始化时间，排查启动顺序问题时特别有用。这个习惯我保持了五六年，救过我好几次。