核心内容摘要
老牛影视文化传媒有限公司官方：用匠心耕耘，用热爱铸就影业新篇章
子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 。
曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑
总结、框架与方案选型思考、行业趋势解读展开。
文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践
总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。
愿我们都能在代码和生活里走得更稳一点 文章目录引言
先划清三层不要一开始就写 UI
文档模型不是数据而是“状态载体”错误理解文档 一段内容正确做法文档是一个“运行态对象”
WorkspacePC 世界的真正核心Workspace 管什么一个最小可用的 Workspace 模型
Controller把“操作流程”从 UI 中拔出来错误UI 直接 orchestrate 一切正确引入 WorkspaceController
UI只是“视图 事件映射”
为什么这套模型特别适合 PC
一个现实世界的对照
总结引言PC 形态下页面不是核心文档才是。
那接下来真正的问题只有一个文档模型到底该怎么设计才能撑住多窗口、状态一致性和长期演进
先划清三层不要一开始就写 UI一个标准的 HarmonyOS PC 文档模型至少拆成三层┌──────────────────┐ │ UI窗口 / 页面 │ └────────▲─────────┘ │ 订阅 ┌────────┴─────────┐ │ 形态模型层 │ ← PC 专属 │ Workspace / Doc │ └────────▲─────────┘ │ 调用 ┌────────┴─────────┐ │ 共用能力层 │ │ Repository / IO │ └──────────────────┘注意顺序UI 最后写模型先稳定能力层完全不关心形态
文档模型不是数据而是“状态载体”错误理解文档 一段内容interfaceDocument{id:stringcontent:string}这只能算存储结构不算模型。
正确做法文档是一个“运行态对象”// pc/model/DocumentModel.tsexportclassDocumentModel{readonlyid:stringcontent:stringisDirty:booleanfalselastFocusedAt:numberDate.now()constructor(doc:Document){this.iddoc.idthis.contentdoc.content}updateContent(newContent:string){this.contentnewContentthis.isDirtytrue}}这里开始出现关键差异文档有生命周期文档知道自己“是否被修改”UI 不再自己维护脏状态
WorkspacePC 世界的真正核心如果只记住一句话那就是PC 应用里Workspace 才是根对象。
Workspace 管什么当前打开了哪些文档文档之间的关系应用级行为保存、关闭、恢复一个最小可用的 Workspace 模型// pc/model/WorkspaceModel.tsexportclassWorkspaceModel{privatedocumentsnewMapstring,DocumentModel()open(doc:Document){if(!this.documents.has(doc.id)){this.documents.set(doc.id,newDocumentModel(doc))}}close(docId:string){this.documents.delete(docId)}list():DocumentModel[]{return[...this.documents.values()]}hasDirtyDocument():boolean{returnthis.list().some(dd.isDirty)}}这里有一个非常重要的工程价值Workspace 是唯一知道“当前应用状态”的地方。
UI 不需要猜Service 不需要猜。
Controller把“操作流程”从 UI 中拔出来错误UI 直接 orchestrate 一切onCloseApp(){if(doc.isDirty){save()}exit()}这种代码一旦出现自动保存批量关闭崩溃恢复全都没法统一。
正确引入 WorkspaceController// pc/controller/WorkspaceController.tsexportclassWorkspaceController{constructor(privateworkspace:WorkspaceModel,privaterepo:DocumentRepository){}saveAll(){for(constdocofthis.workspace.list()){if(doc.isDirty){this.repo.save({id:doc.id,content:doc.content})doc.isDirtyfalse}}}canExit():boolean{return!this.workspace.hasDirtyDocument()}}现在UI 只发意图Controller 统一流程模型是状态来源
UI只是“视图 事件映射”到这一步UI 会变得异常干净。
// EditorWindow.etsStatedocModel!:DocumentModelbuild(){TextArea({text:this.docModel.content}).onChange(vthis.docModel.updateContent(v))}你会发现UI 不保存任何业务状态没有保存逻辑没有生命周期判断UI 只是模型的一个投影。
为什么这套模型特别适合 PC因为它天然支持多窗口多文档后台保存崩溃恢复文档级权限控制而且每一个能力都有清晰落点能力归属是否修改DocumentModel当前打开文档Workspace保存策略Controller展示UI
一个现实世界的对照如果你做过这些产品VS CodePhotoshopKeynoteXcode你会发现它们无一不是文档模型驱动。
HarmonyOS PC 只是终于走到了同一个阶段。
总结HarmonyOS PC 应用的复杂度不来自窗口多而来自你有没有一个能承载复杂度的模型。
没有文档模型 → 状态迟早进 UI没有 Workspace → 多窗口一定崩没有 Controller → 行为一定散