鸿蒙开发中 Model 类的组织方式

这个问题在鸿蒙官方推荐的分层架构中，并不是二选一的单选题 ，两种方式各有适用场景，且两者往往是并存的。

官方推荐：按「分层架构」组织 Model

从华为官方多个参考项目（综合工具模板、多设备设置应用、多设备即时通讯应用等）来看，官方推荐的分层架构将项目分为三层：1

css 复制代码

├── common/          ← 公共能力层
│   └── src/main/ets/
│       └── model/          ← 跨模块共享的 Model
│
├── features/        ← 基础特性层（按功能拆分的 HAR 包）
│   ├── message/
│   │   └── src/main/ets/
│   │       ├── model/      ← 消息模块私有的 Model
│   │       ├── view/
│   │       └── viewmodel/
│   ├── social/
│   │   └── src/main/ets/
│   │       └── model/      ← 社交模块私有的 Model
│   └── payment/
│       └── src/main/ets/
│           └── model/      ← 支付模块私有的 Model
│
└── products/        ← 产品定制层（按设备类型的入口 HAP）

核心原则：

公共的、跨模块共享的 Model → 放在 common 层统一管理
某个功能模块私有的 Model → 放在对应 features 模块内部

两种方式对比

维度	集中存放（common/model/）	分散存放（各 feature 内 model/）
适用对象	多个模块共用的数据模型，如 `UserInfo`、`BaseResponse`、`ApiResult` 等	仅某个模块内部使用的模型，如消息模块的 `ChatMessage`、支付模块的 `OrderDetail`
优点	一处定义、多处复用，减少重复代码；修改时只需改一处	高内聚、低耦合，模块边界清晰；移除功能时直接删除整个模块即可
缺点	公共 model 修改可能影响多个模块，需谨慎评估影响面	如果两个模块需要相同 model，可能出现重复定义
模块独立性	低 --- 模块依赖 common	高 --- 模块完全自包含
维护成本	初期低，后期可能膨胀成"垃圾桶"	短期稍繁琐，长期更清晰

实践建议

1. 按「职责范围」划清边界

typescript 复制代码

// ✅ 放在 common/model/ --- 跨模块通用
// common/src/main/ets/model/UserInfo.ets
export class UserInfo {
  id: string = '';
  name: string = '';
  avatar: string = '';
}

// common/src/main/ets/model/ApiResponse.ets
export class ApiResponse<T> {
  code: number = 0;
  message: string = '';
  data: T | null = null;
}

// ✅ 放在 features/message/model/ --- 消息模块私有
// features/message/src/main/ets/model/ChatMessage.ets
export class ChatMessage {
  msgId: string = '';
  content: string = '';
  timestamp: number = 0;
  sender: string = '';
}

// ✅ 放在 features/payment/model/ --- 支付模块私有
// features/payment/src/main/ets/model/OrderInfo.ets
export class OrderInfo {
  orderId: string = '';
  amount: number = 0;
  status: OrderStatus = OrderStatus.PENDING;
}

2. 小型项目：先简单后重构

如果你的项目功能较少（3~5 个页面），暂时不必强行拆 HAR 模块，把所有 Model 集中放在 entry/src/main/ets/model/ 下是完全可以的：

css 复制代码

entry/
└── src/main/ets/
    ├── model/          ← 所有 Model 放这里，简单直接
    ├── viewmodel/
    ├── view/
    └── pages/

等项目规模增长，再逐步将独立功能抽成 HAR 模块，Model 随之迁移。

3. 避免两种反模式

反模式一 ：把所有 Model 都塞进 common，导致公共模块膨胀成"万能依赖"，任何小改动都可能触发大范围重新编译。
反模式二 ：完全不设公共 Model，导致 UserInfo 这样的基础类型在每个模块里各定义一份，出现不一致的风险。

总结

一句话：公共的放 common，私有的跟 feature 走。

这是鸿蒙官方分层架构的精髓------既避免重复，又保持模块的高内聚和独立可复用性。对于新手或者小型项目，可以先从集中存放起步，待项目成长后自然演进到分层模式。