HarmonyOS应用实战-启示散页-48-HAR 公共模型别引 UI 依赖：让 Deck、Answer 和 Result 保持纯净

HarmonyOS应用实战-启示散页-48-HAR 公共模型别引 UI 依赖让 Deck、Answer 和 Result 保持纯净公共模型一开始只是 Deck、Answer、Favorite。页面需要一个展示字段时开发者很容易顺手把 State、NavPathStack 或页面类型塞进模型。这样数据层开始依赖 ArkUI测试、迁移和跨模块复用都会被页面生命周期拖住。这篇文章解决四件事还原这个问题在答案之书这类离线应用里如何出现。明确页面、Service、Repository、AppStorage 或发布清单各自的责任。给出可迁移的 ArkTS/工程代码片段并说明反例为什么会留下隐患。用验证清单和排障表把方案收成可执行检查项。公共模型一旦懂 UI分层就失效了Deck 和 Answer 是业务事实不应该知道自己在卡片、Sheet 还是结果页里展示。页面需要的折叠状态、选中状态、动画阶段都属于展示模型。把这些字段塞进 HAR会让每个消费者都被迫理解页面状态。已核对的模块职责是HAR 承载 Deck、Answer、Favorite、PreferencesStore、Repository、Tokens 和 RoutesHSP 承载页面与服务。本文强调现有边界并给出静态检查方法。把领域模型、展示模型和页面状态分开先写 owner 表再写代码。否则代码能跑起来却很难说明失败时该由谁回滚、重启后该由谁恢复、其他页面该根据什么信号刷新。Owner负责什么不负责什么HAR models保存 Deck、Answer、Favorite 等纯数据引入 State、Builder、NavPathStackHAR repositories读写本地数据和 schema决定页面交互HSP services把领域数据组装成页面需要的结果污染 HAR 类型ArkUI pages维护展开、选中、动画等临时状态改写领域事实Deck 和 Answer 只保留业务字段模型要表达本链路需要的稳定事实不要把页面临时状态或底层存储细节暴露出去。这样后续迁移 Preferences schema、拆模块或增加发布检查时调用方不必跟着重写。exportinterfaceAnswer{id:string;text:string;sourceDeckId:string;createdAt:number;}exportinterfaceDeck{id:string;name:string;colorKey:string;answers:Answer[];updatedAt:number;}这段模型的重点有三点字段命名贴近业务输入输出能覆盖失败分支没有携带 ArkUI 组件状态。页面拿它展示Service 拿它做判断Repository 不需要知道页面长什么样。展示模型在 HSP 组装不回写 HARService 是规则 owner。凡是涉及校验、回滚、冲突、恢复、隐私或发布证据的逻辑都不要散落在组件回调里。interfaceAnswerCardModel{answerId:string;previewText:string;fullText:string;fromDeckName:string;canFavorite:boolean;}classAnswerCardMapper{toCard(answer:Answer,deck:Deck):AnswerCardModel{constpreviewTextanswer.text.length80?${answer.text.slice(0,80)}...:answer.text;return{answerId:answer.id,previewText,fullText:answer.text,fromDeckName:deck.name,canFavorite:true};}}这里的 Service 不追求复杂抽象只做一件事把输入转成可解释结果。页面可以做乐观交互但最终事实必须从 Service 返回。Repository 返回领域对象不返回页面对象Repository 负责稳定读写、默认值和 schema 兼容。它不弹 Toast不决定按钮状态也不拼页面文案。classDeckRepository{asyncloadDeck(deckId:string):PromiseDeck|null{constrawawaitPreferencesStore.getJsonDeck(deck_store,deckId);if(!raw){returnnull;}returnnormalizeDeck(raw);}}如果这一层缺失页面会被迫知道 store name、key、默认值和异常处理细节。写到后面所有页面都会变成半个仓储层。页面状态留在页面别写进 Answer页面只消费结果、展示状态、触发动作。跨页面刷新用轻量信号完整业务对象继续由 Service 重新读取。Componentstruct AnswerCard{Propmodel:AnswerCardModel;Stateprivateexpanded:booleanfalse;build(){Column(){Text(this.expanded?this.model.fullText:this.model.previewText)Button(this.expanded?收起:查看全文).onClick((){this.expanded!this.expanded;})}}}这类写法的好处是入口可以扩展页面可以重进数据可以迁移。只要 Service 和 Repository 边界稳定页面不需要关心底层怎么保存。反例短期省事长期失控反例是在Answer里增加expanded: boolean、selected: boolean或pathStack: NavPathStack。这些字段只服务某个页面却会污染所有仓储、导入、备份和测试用例。更具体地说反例通常有三个共同点直接写持久化、没有失败结果、没有刷新 owner。它们在单次手测里很难暴露但在重启、返回、跨入口或发布复查时会变成真实问题。排查顺序\n1. 先找唯一写入 owner。\n2. 再看失败是否返回可展示结果。\n3. 再看刷新信号是否只通知相关页面。\n4. 最后才检查 UI 展示。验证路径不要只走正常操作在 HAR 里搜索 ArkUI 装饰器和页面类型确认模型不依赖 UI。用内存仓储测试 DeckRepository确认不需要启动 ArkUI 页面。长答案展示用 AnswerCardModel 截断复制和收藏仍使用 fullText。HSP 页面变更不要求迁移 HAR 存储 schema。验证时建议把“正常路径、异常输入、重启恢复、跨入口刷新、发布态检查”分开记录。构建通过只能证明语法和资源能打包不能证明这些运行链路都已经被真机验证。rg-nPreferencesStore|AppStorage.setOrCreate|Repository|ServiceD:\\ProgramData\\huawei\\lesson\\The_Book_of_Answers\nrg-nquestion|answerText|deckName|hilogD:\\ProgramData\\huawei\\lesson\\The_Book_of_Answers常见问题与处理现象先看哪里处理测试 HAR 时必须引页面包模型是否引用 ArkUI 类型把展示字段移到 HSP备份文件出现 expanded 字段是否序列化页面状态备份只读领域模型多个页面展示互相影响临时状态是否写入 Answer页面状态留在组件内处理这些问题时不要先改 UI 文案。先确认写入 owner、读取 owner 和刷新信号是否一致再看页面是否正确消费结果。若只在页面补一个 Toast用户当次可能看到了提示但重启、返回、跨入口和发布复查仍然会暴露同一个根因。落地取舍这套方案不是为了把轻量应用写重而是为了把真正会跨页面、跨启动、跨发布阶段的事实收住。只影响当前展示节奏的变量可以留在页面会改变用户内容、持久结构、隐私口径或发布证据的逻辑必须进入 Service、Repository 或发布清单。判断点建议位置原因只影响当前按钮、弹层或动画页面State不需要跨入口复用会写本地数据或读持久事实Service Repository需要校验、回滚和恢复会影响其他页面刷新AppStorage 时间戳通知变化不共享完整对象会影响发布、截图、隐私或诊断发布清单或运行账本后续复查需要证据真正落地时可以先从一条最容易复现的路径开始找出唯一写入点补上结果模型再把页面里的直接读写替换成 Service 调用。这个顺序比一次性重构全部页面更稳也更容易在评审时说明每一行代码解决了哪个故障链。评审记录里最好保留对应的命令、截图或复现步骤避免方案只停留在口头约定。小结HAR 的价值是稳定和可复用。Deck、Answer、Result 只描述领域事实页面需要的摘要、展开、按钮状态由 HSP 服务或组件模型生成。这样应用拆包、测试和备份都能围绕纯数据工作不被 ArkUI 生命周期牵住。码解决了哪个故障链。评审记录里最好保留对应的命令、截图或复现步骤避免方案只停留在口头约定。小结HAR 的价值是稳定和可复用。Deck、Answer、Result 只描述领域事实页面需要的摘要、展开、按钮状态由 HSP 服务或组件模型生成。这样应用拆包、测试和备份都能围绕纯数据工作不被 ArkUI 生命周期牵住。