将 TypeORM 实体模型类与 NestJS-GraphQL 模式类型结合使用是否合适?

Jos*_*eph 5 dry typescript graphql typeorm nestjs

我正在使用NestJSTypeORM创建GraphQL API 。从经典的 User 实体开始,我创建了 和,如 Nestjs 文档所述。user.type.tsuser.entity.ts

这是内容的示例:

  • user.entity.ts
@Entity({ schema: 'mydb', name: 'userList' })
export class User {

    @Column('varchar', { name: 'guid', unique: true, length: 36 })
    guid: string;

    @Column('varchar', { name: 'firstName', length: 50 })
    firstName: string;

    @Column('varchar', { name: 'lastName', length: 100 })
    lastName: string;

    // ...
Run Code Online (Sandbox Code Playgroud)
  • user.type.ts
@ObjectType()
export class UserType {
  @Field({
    name: 'ID',
    description: 'Global Universal ID of the User',
  })
  guid: string;

  @Field()
  firstName: string;

  @Field()
  lastName: string;

  // ...
Run Code Online (Sandbox Code Playgroud)

问题是:由于它们使用相同的字段,我可以创建一个结合两个类的装饰器的单个类吗?

例如:

@Entity({ schema: 'mydb', name: 'userList' })
@ObjectType()
export class User {

    @Column('varchar', { name: 'guid', unique: true, length: 36 })
    @Field({
      name: 'ID',
      description: 'Global Universal ID of the User',
    })
    guid: string;

    @Field()
    @Column('varchar', { name: 'firstName', length: 50 })
    firstName: string;

    @Field()
    @Column('varchar', { name: 'lastName', length: 100 })
    lastName: string;
Run Code Online (Sandbox Code Playgroud)

它是反模式吗?这样做有什么限制或缺点吗?

提前致谢

Sko*_*com 5

你可以按照你的建议去做。这不是问题。这样做是个人喜好。

然而,您可能会像我一样很快了解到,尽管从数据结构的角度来看两者具有相同的形状,但实体和 GraphQL 对象(或用 NestJS 术语来说,数据传输对象或 DTO)确实有不同的用途。您还会发现在某些情况下需要从一种转换为另一种,为此需要将它们分开。

  • @Joseph - 我可以举出的一个很好的例子是,您的 API 字段名称应该与数据库的字段名称不同。如果您将实体和 GraphQL 对象一起构建,则 API 名称和实体字段名称必须相同。可能看起来不是一个问题,但它可能是一个问题。 (2认同)
  • 谢谢!是的,我也这么想,但实际上使用 Nestjs 上的 @Field 装饰器,你可以定义字段名称的映射。例如:“@Field({name: ID}) guid: string;”这意味着您的数据库字段称为 guid,但它作为 ID 公开。你也可以@HideField之类的东西。目前我还没有看到限制,但我也会尝试找出它们 (2认同)