NestJS中DAL自定义查询返回类型的命名与实践规范咨询

1. DAL非原模型返回类型的专业命名规范 #

针对这类数据库投影/关联查询后的自定义结果类型，行业内常用的命名方式有以下几种，可根据团队习惯统一选用：

• 后缀用Projection：比如PersonProjection，直接对应MongoDB中projection的操作语义，清晰体现这是数据库字段投影后的结果，完全匹配你的场景。
• 后缀用DalResult/DalOutput：比如PersonDalResult，明确标识这是DAL层的输出类型，和业务层的DTO、领域模型做明确区分，避免概念混淆。
• 基于结构语义命名：比如PersonNameWithBirthDate，如果类型结构独特且字段明确，用直接描述字段组合的命名方式，可读性极强。
• 后缀用View：比如PersonBasicInfoView，若该类型对应数据库逻辑视图（或虚拟视图）的结构，用View后缀也很合理。

核心原则是团队内保持命名风格统一，避免同一项目中混用多种后缀，减少认知成本。

举个TypeScript类型定义的例子：

// DAL层返回的自定义类型
export type PersonProjection = {
  name: string;
  birthDate: Date;
};

2. 返回原模型时是否需要创建自定义返回类型？ #

建议优先创建自定义返回类型，原因如下：

• 解耦依赖：将DAL层输出与数据库实体模型解耦。后续若实体模型新增/修改字段（比如添加敏感字段passwordHash），只需调整DAL的自定义类型，上层Service/Controller无需修改，避免意外暴露不必要的字段。
• 类型安全：在TypeScript中，直接返回实体模型可能会包含数据库层面的冗余字段（比如_id、createdAt），自定义类型可以精确控制返回字段范围，避免上层业务代码误用无关字段。
• 扩展性：未来如果需要对DAL查询做调整（比如新增关联查询、字段投影），直接修改自定义类型即可，无需改动上层的类型依赖，适配需求变更更灵活。

如果是极简单的CRUD场景，且实体模型与业务需求完全一致、短期内无变动可能，也可以暂时直接返回实体模型，但从长期维护角度看，自定义类型的收益更高。

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