TypeORM 是一款基于 TypeScript 的 ORM（对象关系映射）工具，核心作用是 简化数据库操作，它允许开发者通过面向对象的方式（类、对象） 操作数据库，无需直接编写复杂的 SQL 语句，同时支持 MySQL、PostgreSQL、MongoDB 等多种数据库。

TypeORM 是 NestJS 生态中数据库交互的主流方案，而 Entity（实体类）是 TypeORM 的核心概念，二者是框架工具与核心载体的关系。

对象与数据库的映射桥梁

ORM 的本质是「将代码中的对象与数据库中的表 / 文档一一对应」。

• 用 TypeScript 类描述数据库表结构；
• 用类的实例对应表中的一行数据；
• 用类的属性对应表的字段，开发者操作对象，TypeORM 自动转换成 SQL 执行，大幅降低数据库操作的复杂度。

简化 CRUD 与复杂查询：提供 Repository/EntityManager 等工具类，封装了增删改查、联表查询、分页排序等常用操作，无需手写 SQL。例如：

// 通过实体类 User 直接查询所有用户
const users = await this.userRepository.find();

支持迁移（Migration）：数据库表结构的变更可以通过「迁移文件」版本化管理，团队协作时能保证所有人的数据库结构一致，避免手动改表导致的冲突。

与 NestJS 深度集成：NestJS 提供了 @nestjs/typeorm 模块，可通过依赖注入的方式快速将 TypeORM 功能注入到 Service 中，符合 NestJS 的模块化、解耦设计思想。

---

Entity 是 TypeORM 定义数据库表结构的核心载体，本质是一个 被 @Entity() 装饰器标记的 TypeScript 类。

Entity 类的基本写法

// user.entity.ts
import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity() // 标记此类为实体，对应数据库中的 `user` 表（默认类名小写）
export class User {
  @PrimaryGeneratedColumn() // 标记为主键，自增
  id: number;

  @Column({ length: 50 }) // 对应表的字段，长度 50
  username: string;

  @Column({ default: true }) // 字段默认值 true
  isActive: boolean;
}

@Entity()：装饰器，告诉 TypeORM 这是一个实体类；

@PrimaryGeneratedColumn()：定义主键，自增 ID；

@Column()：定义普通字段，可配置长度、默认值、是否非空等属性。

---

总结

TypeORM 是 NestJS 中用于数据库交互的 ORM 工具，核心是「对象 ↔ 数据库」的映射；

Entity 实体类 是 TypeORM 的映射载体，类 ↔ 数据库表，属性 ↔ 表字段；

开发流程：定义 Entity → 配置 TypeORM 模块 → 用 Repository 操作数据，全程无需手写 SQL（复杂场景也支持原生 SQL）。

---

自动创建数据库表 的功能，是 TypeORM 中的 synchronize: true 配置在起作用，这个功能和 数据库迁移（Migration） 是 TypeORM 中管理表结构的 两种不同方式

二者各有适用场景，开发时用的自动同步很方便，但生产环境更推荐用迁移来管理表结构。

原理：当你在 NestJS 的 TypeORM 配置中设置 synchronize: true 时，TypeORM 会在应用启动时，自动对比 Entity 实体类的结构和数据库中的表结构：

• 如果表不存在：直接根据 Entity 生成对应的表；
• 如果表已存在：自动修改表结构（新增字段、调整字段类型等），匹配 Entity 的定义。

迁移是 TypeORM 提供的 版本化管理表结构 的工具，本质是一组可执行、可回滚的 SQL 脚本，用于替代开发环境的 synchronize 配置。

核心思想

• 每一次表结构变更（建表、加字段、改索引），都生成一个迁移文件，记录「变更操作」和「回滚操作」；
• 应用启动时，TypeORM 会检查数据库中已执行的迁移记录，只执行未执行的迁移脚本；
• 支持回滚：如果变更出错，可以执行回滚脚本恢复到之前的表结构。

---

GraphQL 是 Facebook 开发的一种用于 API 的查询语言和运行时环境，核心目标是解决传统 RESTful API 的痛点，让前端能按需获取数据，而非后端固定返回全量数据。

维度	RESTful API	GraphQL
数据获取	后端定义接口返回固定字段，前端可能拿到冗余数据	前端自定义查询字段，精确获取需要的数据
接口数量	一个资源对应一个接口（如 /users//users/:id）	通常只有 一个入口端点（如 /graphql）
多资源请求	需发送多次请求（如先查用户，再查用户订单）	一次请求获取多个关联资源数据
版本管理	需发布新版本（如 /v1/users//v2/users）	无需版本迭代，新增字段不影响旧查询

GraphQL 和 TypeORM 没有直接的依赖关系，但在 NestJS 等后端项目中，二者是协同工作的 “黄金搭档”，分别负责不同的核心环节：

• TypeORM：负责 “数据库交互”（连接数据库、定义表结构、CRUD 操作），是数据源层的工具。
• GraphQL：负责 “API 数据交互”（定义前端能请求的接口、处理前端查询、返回按需数据），是接口层的规范。

协同工作流程（以 NestJS 为例）

你可以把这个流程理解为 “前端 → GraphQL → Resolver → TypeORM → 数据库” 的数据链路：

定义 Entity（TypeORM 层）

用 TypeORM 实体类映射数据库表，比如 User 实体：

// user.entity.ts
import { Entity, Column, PrimaryGeneratedColumn, OneToMany } from 'typeorm';
import { Post } from './post.entity';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  username: string;

  @Column({ nullable: true })
  email: string;

  @OneToMany(() => Post, post => post.author)
  posts: Post[];
}

定义 GraphQL Schema（GraphQL 层）

在 NestJS 中，通常用装饰器（@ObjectType()/@Query()）定义 Schema，和 Entity 结构对应但独立：

// user.type.ts
import { ObjectType, Field, ID } from '@nestjs/graphql';
import { PostType } from './post.type';

@ObjectType() // 标记为 GraphQL 类型
export class UserType {
  @Field(() => ID) // 映射 GraphQL 的 ID 类型
  id: number;

  @Field()
  username: string;

  @Field({ nullable: true }) // 允许为空
  email?: string;

  @Field(() => [PostType]) // 关联 Post 类型
  posts: PostType[];
}

编写 Resolver（核心桥梁）

Resolver 是二者的 “连接器”：它调用 TypeORM 的 Repository 操作数据库，然后将数据转换为 GraphQL 定义的类型返回给前端。

// user.resolver.ts
import { Resolver, Query, Args, ID } from '@nestjs/graphql';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { UserType } from './user.type';
import { User } from './user.entity';

@Resolver(() => UserType)
export class UserResolver {
  // 注入 TypeORM 的 User 仓库（数据源）
  constructor(
    @InjectRepository(User)
    private userRepository: Repository<User>,
  ) {}

  // 实现 Schema 中定义的 getUser 查询
  @Query(() => UserType)
  async getUser(@Args('id', { type: () => ID }) id: string) {
    // 用 TypeORM 从数据库查询用户
    const user = await this.userRepository.findOne({
      where: { id: parseInt(id) },
      relations: ['posts'], // 关联查询用户的帖子
    });
    return user; // 自动转换为 UserType 返回给前端
  }
}

前端请求数据

前端通过 /graphql 端点发送查询，按需获取数据，Resolver 会调用 TypeORM 从数据库取数并返回：

# 前端查询
query {
  getUser(id: "1") {
    id
    username
    posts { title } # 只取帖子标题
  }
}

核心区别与联系总结

关系	具体说明
核心定位不同	TypeORM：数据库工具，解决 “代码 ↔ 数据库” 的映射问题 GraphQL：API 规范，解决 “前端 ↔ 后端” 的数据交互问题
无直接依赖	二者可以独立使用：GraphQL 可以对接任何数据源（MySQL/Redis/ 第三方 API），不一定用 TypeORM；TypeORM 也可以配合 RESTful API 使用
协同价值	在 NestJS 项目中，二者结合能实现 “数据库表 → 实体类 → GraphQL 类型 → 前端查询” 的完整链路，大幅提升开发效率：1. Entity 和 GraphQL Type 结构可复用，减少重复定义2. Resolver 层通过 TypeORM 统一管理数据库操作，逻辑清晰3. 前端按需取数，减轻后端数据处理压力

总结：TypeORM 负责 “从数据库拿数据”，GraphQL 负责 “把数据给前端”，Resolver 是中间的 “搬运工”。****

贡献者: yumengjh

上一页应用架构设计

下一页控制器