LESSON 25 / 575 分钟
轻量架构、依赖注入与测试替身
为小应用保留清晰边界，就足以让你和 AI 安全地迭代。
用你的前端经验理解
View ≈ UI 组件；Model/状态模型 ≈ store；Service ≈ API 层。MVVM 是一种组织方式，不是 SwiftUI 必须采用的标准。
01 / 理解问题
为什么需要它
对小型应用，架构的目标是让变化有位置、错误可定位、逻辑能测试。你不需要先实现一套抽象框架。可以从 View、功能状态模型和仓库三个职责开始：View 呈现状态，模型组织动作，仓库处理网络或磁盘。只有当重复和依赖边界确实出现时再继续拆分。
它是怎样工作的
依赖注入就是从外部提供所需能力，最简单形式是初始化器参数。把具体 URLSession 请求藏在仓库后面，可以在测试中换成固定数据；但协议应围绕调用方的实际需求设计。状态更新由明确所有者负责，避免 View、单例和仓库各自保存不同版本的同一数组。
02 / 掌握要点
把关键概念连起来
1
边界
View 负责展示和交互意图；业务规则放模型或服务；网络与存储通过明确接口访问。
2
依赖
从初始化参数或环境注入服务，避免随处创建单例。测试时替换成可控制的 mock。
3
尺度
简单页面可直接使用 SwiftUI 状态。出现重复逻辑、多来源数据或复杂状态流时再抽离模型。旧项目也可能使用 Combine 的 Publisher、订阅与取消来组织事件流；它不等同于 Observation。
03 / 案例推演
为“添加文章”建立最小边界
- View 收集标题与网址，调用功能模型的 add 动作；模型验证输入并切换提交状态。
- 仓库返回保存结果或错误。成功后模型更新可见数据，失败时保留草稿，View 只根据状态决定提示。
- 测试注入失败仓库，无需真实断网即可验证“错误后草稿仍在、按钮恢复可用”。
这里需要你亲自判断
不要让 AI 一次生成十层架构。先做到一条垂直业务流程可运行、可解释、可测试。
04 / 动手验证
做一个小练习
将“加载阅读清单”抽成一个依赖，并在预览里注入固定数据与失败结果。
- 画出 View→模型→仓库的依赖方向，标出哪些对象允许调用系统 API。
- 实现一个固定失败的测试替身，验证页面动作不会误报成功。
展开参考思路与验收标准
可测试的核心是依赖边界，不是文件数量。不要让仓库反向引用 View，也不要为了一个只有一次使用的纯函数引入多层工厂和管理器。
05 / 检查理解
依赖注入最直接带来什么？
答对理解题后即可标记完成