NestJS GraphQL复用类作为输入输出类型的合理性探讨

你的这种做法完全合理，尤其针对Location这类无复杂业务逻辑的简单值对象，复用类同时作为输入和输出类型是NestJS代码优先范式下的可行方案，下面具体说说细节和注意事项：

• 当前实现的正确性：你给Location类同时添加@ObjectType()和@InputType('LocationInput')装饰器的方式，是NestJS官方支持的用法。这样会自动生成两个独立的Schema类型（一个用于输出，一个用于输入），既满足了GraphQL对输入输出类型分离的要求，又避免了重复编写结构一致的代码。

• 适用场景的边界：像Location这种仅包含基础数据字段、无输入专属校验逻辑（比如仅需通用格式校验）、无输出专属字段（比如数据库自动生成的ID、创建时间）的类，完全适合复用。在MyInput（输入类型）和MyPlace（输出类型）中共用，能有效减少代码冗余，提升维护效率。

• 需要注意的关键点：

  • 必须给@InputType()指定唯一名称（比如LocationInput），避免和@ObjectType()生成的类型名冲突，否则会导致Schema生成失败或出现类型混淆。
  • 一旦后续需要给这个类添加输入专属的校验规则（比如@Min()、@Max()这类仅输入时需要的校验），或者输出专属的字段（比如关联的其他实体、数据库元数据），就必须拆分出独立的LocationInput和Location类，不能再复用，否则会导致逻辑混乱或Schema不符合预期。

• 示例代码参考：

// location.ts
import { ObjectType, InputType, Field } from '@nestjs/graphql';
import { IsLatitude, IsLongitude } from 'class-validator';

// 同时标记为ObjectType和InputType，指定InputType的名称
@ObjectType()
@InputType('LocationInput')
export class Location {
  @Field()
  @IsLatitude() // 通用校验可以直接加在这里，输入输出都会生效
  latitude: string;

  @Field()
  @IsLongitude()
  longitude: string;
}

// my-input.ts
@InputType()
export class MyInput {
  // 使用InputType的名称指定类型
  @Field(() => LocationInput)
  targetLocation: Location;
}

// my-place.ts
@ObjectType()
export class MyPlace {
  // 使用原始类作为输出类型
  @Field(() => Location)
  location: Location;
}

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