Angular中def接口与dto接口的区别及使用场景

两类文件是前端分层架构里的典型约定，本质定位完全不同：

• Def（Definition 的缩写）：前端内部维护的业务领域模型定义，是前端业务逻辑里通用的标准数据结构，完全服务于前端自身的业务、交互需求，不受后端接口结构变动的影响。
• DTO（Data Transfer Object 的缩写）：跨端数据传输专用结构，字段、嵌套层级100%对齐后端接口的入参、返回值规范，只在和后端交互的边界层使用，不会直接流入前端核心业务逻辑。

vendor-def.interface.ts 的典型特征 #

这个文件里的所有接口都服务于前端内部场景：

import { SourceType, VendorType } from '../shared/enums/vendor-type.enum';

export interface VendorDef {
  vendorId: string;
  companyCode: string;
  name: string;
  acronym: string;
  alias: string;
  legalId: string;
  vendorType: VendorType;
  sourceType: SourceType;
  fiscalCode: string;
}


export interface VendorFormDef {
  sourceType: SourceType;
  companyCode?: string;
  previousMainCompany?: string;
}

export interface InUsageDef {
  acronym: boolean;
  legalId: boolean;
  fiscalCode: boolean;
}

• VendorDef是前端业务层对「供应商」这个实体的标准定义，是扁平的、业务可直接使用的结构，没有接口规范要求的冗余包装层，包含alias这类前端业务需要但后端接口不一定返回的字段。
• VendorFormDef是前端表单组件绑定的数值结构，包含previousMainCompany这类纯前端交互流程才会用到的字段，后端不需要感知这个字段。
• InUsageDef是前端做字段重复性校验时用的状态结构，完全属于前端内部逻辑，和后端接口没有关联。

vendor-dto.interface.ts 的典型特征 #

这个文件里的结构完全对齐后端接口规则：

import { SourceType, VendorType } from '../shared/enums/vendor-type.enum';

export interface VendorDto {
  data: VendorDataDto[] | VendorDataDto;
  errors?: VendorErrorsDto;
}

export interface VendorDataDto {
  attributes: VendorAttributesDto;
  id: string;
}

export interface VendorErrorsDto {
  code: string;
  title: string;
  detail: string;
}

export interface VendorCreateDto {
  companyCode: string;
  name: string;
  acronym: string;
  legalId: string;
  fiscalCode: string;
  vendorType: VendorType;
  sourceType: SourceType;
}

• 最外层VendorDto包含data、errors字段，是典型的遵循JSON:API类规范的接口返回包装结构，业务逻辑不会直接使用这个嵌套结构。
• VendorDataDto嵌套的attributes层也是接口规范强制要求的层级，不属于业务直接消费的扁平结构。
• VendorCreateDto是调用创建供应商接口时的入参结构，字段和后端要求完全一一对应，没有前端独有的业务、交互字段。

直接按场景判断即可，不需要纠结：

• 用 DTO 的场景：
  • 定义后端接口的返回值接收类型
  • 定义发送给后端的接口请求入参类型

  注意：DTO 只允许出现在接口请求封装层（service/api 目录下的代码），拿到接口返回值后需要先把 DTO 转换成对应的 Def 结构，再传给状态管理、组件等业务逻辑层使用。

• 用 Def 的场景：
  • 定义全局/页面状态管理中存储的业务实体结构
  • 定义组件传参（Props）、组件内部状态的类型
  • 定义表单、前端校验、交互逻辑等纯前端场景的数据结构

  注意：不要直接把 Def 结构作为请求参数传给后端，发请求前需要先把业务层的 Def 转换成后端要求的 DTO 结构再提交。

这种分层命名的核心作用是解耦前后端：后续如果后端调整接口结构、修改返回字段嵌套逻辑，你只需要修改 DTO 定义和对应的转换函数，不需要改动项目里所有和供应商业务相关的组件、逻辑代码。

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