【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战之补充【架构进化】灵犀厨房四层分层设计：给鸿蒙 App 搭一副坚不可摧的骨架

【架构进化】灵犀厨房四层分层设计：给鸿蒙 App 搭一副坚不可摧的骨架

摘要：当你写完购物清单，看着 pages 目录下横七竖八的十几个文件，是不是觉得《灵犀厨房》越来越像一间堆满食材却找不到盐的厨房？今天我们不写具体功能，而是拿起"架构的手术刀"，对整个项目做一次深度的分层重构。在这篇文章中，我会用"四层装甲车"的比喻，带你彻底搞懂 UI → ViewModel → Business → Services → Foundation 的依赖关系；同时结合 HarmonyOS 6.1.0 的 @ObservedV2、@ComponentV2 等新特性，绘制出一张攻守兼备的架构蓝图。读完你会发现------好的架构，会让未来的每一行代码都写在正确的位置上。

引言与系列定位

在上一篇文章（第 10 篇）中，我们顺利地把散落的勾选食材聚合成了一张漂亮的分组购物清单。但当我们得意地审视项目目录时，一个危险的信号出现了：pages/Index.ets 里竟然同时揉杂了推荐算法、状态管理、甚至还有一段临时硬编码的模拟数据。这就像把菜刀、砧板、调料瓶全都丢进同一个水槽------看似方便，一旦要加新功能，整个厨房都会乱套。

所以，在应用正式上架申请成功后，我们将向 Health Kit 健康数据发起冲锋前，不过现在我们必须先停一停，为《灵犀厨房》做一次彻底的 "架构手术" 。本文将交付一份可落地、可扩展的 四层分层架构 v2.0，它将彻底解决以下痛点：

代码耦合严重，改一个 UI 却触发了业务逻辑崩溃
状态管理随心所欲，@State、@Link、@Provide 满天飞
模拟数据和真实服务混杂，想接入 Health Kit 都无从下手

读完之后，你会清晰地知道：什么样的代码该放进 business/，什么样的文件能直接触碰 @kit.HealthKit，以及如何用 ViewModel 像胶水一样把 UI 与业务优雅粘合。

核心原理与底层机制深度解读

要理解这版架构的精髓，我们不妨把《灵犀厨房》想象成一辆 四层装甲车（图 1）：

外挂装甲（UI 层）：负责抵挡用户的点击与滑动，只关心"长什么样"，绝不让一枚子弹穿透到内部。
火控计算机（ViewModel 层）：接收 UI 的指令，计算并组织需要用到的数据，但它不扣扳机。
弹药系统（Business 层）：真正的业务规则所在，例如"从 10 道菜里筛出 4 道不辣且低于 500 大卡的推荐"。
引擎与底盘（Services 层）：封装最底层的系统能力，比如调用 Health Kit、数据库、通知推送。它们只提供动力，不关心你往哪儿开。
零件图纸（Foundation 层） ：纯粹的数据结构，像 Recipe、UserPreference，是全体模块的唯一语言。

在 HarmonyOS 中，这种分层之所以能生效，靠的是 依赖倒置 和 V2 状态管理 的精确配合。@ObservedV2 装饰的 ViewModel 类就像指挥塔，通过 @Trace 属性把"弹药状态"实时同步给 UI 层的雷达屏幕。而 Business 层则完全不知道 UI 的存在，它只是对着空气（接口）开火。这就保证了当我们后续将模拟厨电换成真实分布式软总线时，只需要替换 Business 层的一个模块，UI 层连一个像素都不会抖动。

关键知识点详解

面对中大型鸿蒙应用，架构选型通常有三条路：

架构模式	核心思想	优点	缺点	《灵犀厨房》适用性
MVVM 轻架构	每个页面配一个 ViewModel，Model 层直接操作数据	简单、上手快	业务逻辑容易在 ViewModel 中膨胀，跨页面复用困难	❌ 前期可用，后期难以维护购物清单、健康分析等多模块交互
VIPER/Clean Architecture	严格的 Interactor、Presenter、Router 分离	高度解耦，可测试性极强	模板代码过多，对中小型应用性价比低	❌ 团队只有你一人，过度设计
四层分层架构（本文方案）	UI-ViewModel-Business-Services 清晰切分，Foundation 作为数据基座	兼具清晰边界与务实灵活，符合鸿蒙组件化思想	需要严格遵循依赖规则，初期需要一定学习成本	✅ 最佳平衡点，完美适配《灵犀厨房》的功能增长曲线

同时，对比一下状态管理方案的进化：

方案	装饰器	性能	类属性观测	跨组件共享	《灵犀厨房》v2.0 选型
V1 状态管理	`@State`、`@Link`、`@Provide` 等	一般，易触发冗余渲染	不支持类属性级监听	复杂且需手动 `@Provide` / `@Consume`	❌ 已在第 9 篇被 V2 替代
V2 状态管理	`@ObservedV2`、`@Trace`、`@Local`、`@Param`	精准更新，性能提升明显	`@Trace` 可监听类成员变量	通过 `@Provider()` / `@Consumer()` 简洁优雅	✅ 本次架构重构的唯一选择

架构设计 / 核心逻辑图解

话不多说，上"骨相图"。下面这张 Mermaid 关系图，揭示了《灵犀厨房》v2.0 的五层依赖与四大数据流。
Foundation 层
Services 层
Business 层
UI 层 (pages/components)
ViewModel 层
MainContainer

Tab导航
HomeViewModel
RecipeDetailPage
IngredientViewModel
ShoppingListPage
ShoppingListVM
HealthDashboard
HealthDashboardVM
KitchenDevice
KitchenDeviceVM
ProfilePage
ProfileViewModel
RecommendEngine
RecipeManager
ShoppingList
NutritionAnalyzer
KitchenDeviceSimulator
HealthServiceHelper
NotificationHelper
RelationalStoreHelper
Recipe
UserPreference
MockData

架构师解读 ：注意所有依赖箭头都是从上往下，且 Services 层绝不反向引用 Business 或 UI。这就奠定了"上层易变，底层稳定"的演化基础。

再来看一条最典型的推荐数据流是如何在四层间起舞的：
MockData RecommendEngine HomeViewModel HomeTabContent MockData RecommendEngine HomeViewModel HomeTabContent "refreshByPreference()" "isLoading = true" "getRecommendations(pref, 4)" "读取全量菜谱" "忌口过滤 + 卡路里筛选" "多维加权评分 (偏好+季节+去重)" "4条推荐Recipe数组" "recommendedRecipes = result, isLoading = false" "Trace 触发精准渲染"

实战：分层架构的落地与模块化搬迁

架构图再漂亮，不落地就是一张废纸。我们根据这张蓝图，对《灵犀厨房》的工程目录做了一次精准的"器官移植"。

Step 1：重新定义 Foundation 层------让数据模型成为单一真相源

首先，把散落在各处的 FoodItem、Recipe 等类型统一收口到 foundation/model/。这里不得存在任何 import router 或 @kit，只能有纯血统的 class 和 interface。

typescript 复制代码

// foundation/model/Recipe.ets
export class Recipe {
  id: number = 0
  name: string = ''
  cover: Resource = $r('app.media.default_cover')
  ingredientItems: IngredientItem[] = []
  tags: string[] = []
  calories: number = 0
  // ...
}

export class IngredientItem {
  name: string = ''
  amount: string = ''
  isChecked: boolean = false
}

变化点解读 ：相比第 4 篇时 model/ 下的混乱，现在的 Foundation 层连一个 @State 都不允许出现。它就像国际度量衡局，只负责定义"米"和"千克"，绝不参与买卖。

Step 2：提取 Business 层------把"智慧大脑"独立出来

将原来嵌在 Index.ets 中的推荐逻辑，重构为 business/RecommendEngine.ets 的单例。同样的手术也用在菜谱管理、购物清单分组上。

typescript 复制代码

// business/RecommendEngine.ets
import { Recipe } from '../foundation/model/Recipe'
import { UserPreference } from '../foundation/model/UserPreference'
import { MockData } from '../foundation/model/MockData'

class RecommendEngine {
  getRecommendations(pref: UserPreference, count: number): Recipe[] {
    // 1. 从 MockData 全量获取
    let candidates = MockData.getAllRecipes()
    // 2. 忌口过滤
    candidates = candidates.filter(r => 
      !r.tags.some(tag => pref.allergies.includes(tag))
    )
    // 3. 多维度评分排序...
    // 4. 去重并返回
    return candidates.slice(0, count)
  }
}
export const recommendEngine = new RecommendEngine()

核心点解读 ：现在，即便我们把 MockData 替换为远端 API 或 Health Kit 实时数据，也只需在这个黑盒内部修改。ViewModel 和 UI 完全无感。

Step 3：固实 ViewModel 管道------用 @ObservedV2 粘合一切

每个复杂页面搭配专属 ViewModel，它只负责做两件事：调用 Business 层获取数据 ，以及用 @Trace 属性驱动 UI 刷新。

typescript 复制代码

// viewmodel/HomeViewModel.ets
import { recommendEngine } from '../business/RecommendEngine'
import { Recipe } from '../foundation/model/Recipe'

@ObservedV2
export class HomeViewModel {
  @Trace recommendedRecipes: Recipe[] = []
  @Trace isLoading: boolean = false

  refreshByPreference(pref: UserPreference) {
    this.isLoading = true
    this.recommendedRecipes = recommendEngine.getRecommendations(pref, 4)
    this.isLoading = false
  }
}

Step 4：UI 层瘦身------用 @ComponentV2 + @Local 拥抱 ViewModel

MainContainer 内的每个 Tab 都变成了一个干净的 @ComponentV2，仅持有自己的 ViewModel 实例，并把它通过 @BuilderParam 或组件树向下传递。

typescript 复制代码

// pages/MainContainer.ets 中 HomeTab 的片段
@ComponentV2
struct HomeTabContent {
  @Local homeVM: HomeViewModel = new HomeViewModel()
  build() {
    Column() {
      if (this.homeVM.isLoading) {
        LoadingProgress()
      } else {
        List() {
          ForEach(this.homeVM.recommendedRecipes, (recipe: Recipe) => {
            ListItem() { RecommendCard({ recipe: recipe }) }
          })
        }
      }
    }
  }
}

变化点解读 ：UI 层彻底扔掉了所有 if-else 业务判断，它的 build() 方法就像一个哑巴服务员，只负责端盘子，不负责炒菜。

Step 5：Services 层预留接口------为 Health Kit 腾出空间

我们在 services/HealthServiceHelper.ets 中预埋了一个桩（Stub），它目前返回模拟数据，但完整实现了 calculateNutritionBudget 所需的一切签名。第 12 篇接入真实 Health Kit 时，只需要填充其内部实现。

运行与结果验证

现在我们执行一次全量编译，并通过 DevEco Studio 的依赖分析插件查看模块耦合度。

期望输出（在 Log 中通过代码显式打印，验证分层是否生效）：

text 复制代码

[灵犀厨房-架构] 当前首页推荐引擎已独立加载，依赖链: UI→HomeViewModel→RecommendEngine→MockData
[灵犀厨房-架构] 未检测到 business 层对 @kit.HealthKit 的直接引用，分层规则校验通过。

日志解读 ：

这串日志虽然是我们刻意埋下的"架构哨兵"，但它真实地反映出四层分层的约束力。当我们后续新增 HealthKit 接入时，如果发现编译报错 Cannot find module '@kit.HealthKit' 出现在 business/ 目录下，就说明有人试图越界开火，必须立刻修正。

本阶段总结与下篇预告

今天，我们没有为《灵犀厨房》添加任何一个用户可见的新按钮，但却完成了整个项目最昂贵的投资------架构。我们用四层装甲车的模型，把脆弱的代码堆砌重构为 UI、ViewModel、Business、Services、Foundation 五大清晰阵地，并依托 HarmonyOS 6.1.0 的 V2 状态管理，实现了编译期的依赖约束和运行时的精准渲染。

地基已经夯实到足以承载摩天大楼。这篇作为《灵犀厨房》架构补充篇。在后续等应用完成上架后，我们将正式驾驶这辆装甲车，冲进【数据打通】访问 Health Kit 获取健康数据的战场。届时，你会看到 HealthServiceHelper 如何从 Stub 蜕变成真正的健康数据管道，而你的菜谱推荐也将第一次拥有卡路里和步数的科学依据。我们下期见！

📚 本系列持续更新中：下一篇，我们将完成【营养分析引擎】计算个性化卡路里建议新篇章，敬请期待。

🔗 专栏入口 ：[《从0到1开发灵犀厨房App》合集] | ⭐ 源码：Gitee 仓库