Angular中Workout DTO分含完整对象/仅ID的设计是否合规及命名规范

这种做法是不是不良实践？ #

完全不是，反而是推荐的最佳实践。

不同业务场景对DTO的需求差异很大：

• 列表页只需要Workout基础信息+关联ID，就能实现跳转或关联展示，不需要完整的ExerciseSet数据，减少传输量；
• 详情页需要完整的关联数据来渲染所有信息；
• 创建/更新场景可能需要未生成ID的半完整集合数据。

通过基础DTO扩展出不同场景的专用DTO，能：

• 明确区分各场景的数据结构，避免类型模糊；
• 减少冗余数据传输，提升性能；
• 利用TypeScript的类型检查，避免在错误场景下使用错误的数据结构，降低bug率。

命名规范参考 #

没有绝对统一的行业标准，但有几种常用的约定，团队内统一即可：

1. 基于关联数据形式命名（你的示例思路） #

这种方式直观易懂，一眼就能看出DTO包含的关联数据类型：

export interface WorkoutDto{
  id: string;
  // Workout自身其他字段
}

// 包含完整ExerciseSet数据
export interface WorkoutWithExerciseSetDto extends WorkoutDto{
  exerciseSet: ExerciseSetDto;
}

// 仅包含ExerciseSet的ID
export interface WorkoutWithExerciseSetIdDto extends WorkoutDto{
  exerciseSet: string;
}

// 针对未生成ID的集合场景
export interface WorkoutWithUnsavedExerciseSetDto extends WorkoutDto{
  exerciseSet: Omit<ExerciseSetDto, 'id'>; // 排除ID字段，确保类型严谨
}

2. 基于业务场景命名 #

如果DTO的用途和业务场景强绑定，这种命名方式更贴合实际使用：

export interface WorkoutDto{
  id: string;
  // Workout自身其他字段
}

// 详情页用，包含完整关联数据
export interface WorkoutDetailDto extends WorkoutDto{
  exerciseSet: ExerciseSetDto;
}

// 列表页用，仅带关联ID
export interface WorkoutListItemDto extends WorkoutDto{
  exerciseSetId: string; // 字段名改为exerciseSetId，比泛用的exerciseSet更清晰
}

// 创建Workout时用，支持未保存的ExerciseSet
export interface WorkoutCreateDto extends WorkoutDto{
  exerciseSet: Omit<ExerciseSetDto, 'id'> | string; // 允许传新集合或已有ID
}

命名小建议 #

• 如果字段是关联ID，直接命名为exerciseSetId比exerciseSet: string更直观，避免类型歧义；
• 对于未生成ID的场景，明确标注Unsaved或用Create/Draft这类前缀，让其他开发者一眼明白用途。

总结 #

拆分专用DTO是合理且高效的做法，命名只要团队内部达成一致、语义清晰即可。重点是让每个DTO的用途和数据结构一一对应，避免“万能DTO”带来的混乱。

内容的提问来源于stack exchange，提问作者Mats