TypeORM или Prisma: интеграция ORM

TypeORM: истина — это entities, repository инжектятся

В пути TypeORM ты один раз настраиваешь DataSource в корне, затем регистрируешь entities по фиче-модулям. Подключение асинхронно, потому что его значения приходят из ConfigService, — поэтому берёшь TypeOrmModule.forRootAsync с useFactory, а не статический forRoot:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { User } from './user.entity';

@Module({
  imports: [
    TypeOrmModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        type: 'postgres',
        host: config.get('DB_HOST'),
        port: config.get<number>('DB_PORT'),
        username: config.get('DB_USER'),
        password: config.get('DB_PASS'),
        database: config.get('DB_NAME'),
        entities: [User],
        synchronize: false, // НИКОГДА не true в production
      }),
    }),
  ],
})
export class AppModule {}

Entity — это обычный класс, помеченный @Entity(), и его колонки — это схема:

import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm';

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

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

  @Column({ default: true })
  isActive: boolean;
}

Метаданные этого декоратора и есть источник истины для типобезопасности — TypeScript-класс задаёт и рантайм-маппинг колонок, и генератор миграций. Чтобы использовать entity в фиче-модуле, ты регистрируешь его через forFeature, который провайдит для него repository в DI-контейнер, и инжектишь этот repository через @InjectRepository:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './user.entity';
import { UsersService } from './users.service';

@Module({
  imports: [TypeOrmModule.forFeature([User])], // провайдит Repository<User>
  providers: [UsersService],
})
export class UsersModule {}

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly users: Repository<User>,
  ) {}

  findActive(): Promise<User[]> {
    return this.users.find({ where: { isActive: true } });
  }
}

Repository<User> — это граница персистентности: твой сервис говорит с ней, а не с сырым SQL или глобальным клиентом. Это DI-нативно — repository является обычным провайдером Nest, который мокается в тестах подменой провайдера getRepositoryToken(User).

Prisma: истина — это схема, клиент ты оборачиваешь сам

Prisma переворачивает источник истины. Один файл schema.prisma объявляет модели; prisma generate читает его и выдаёт полностью типизированный клиент. Ты не пишешь entity-классы — схема генерирует типы:

// schema.prisma
generator client {
  provider = "prisma-client-js"
}

model User {
  id       Int     @id @default(autoincrement())
  email    String  @unique
  isActive Boolean @default(true)
}

У Nest нет первоклассного Prisma-провайдера для DI, поэтому ты предоставляешь его сам: injectable PrismaService, который наследует сгенерированный PrismaClient и открывает подключение в onModuleInit. Это та интеграционная обвязка, которую ты пишешь руками:

import { Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }
}

Предоставь его один раз, затем инжекти единственный сервис — нет per-entity @InjectRepository, только типизированные аксессоры моделей на клиенте:

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service';
import { User } from '@prisma/client';

@Injectable()
export class UsersService {
  constructor(private readonly prisma: PrismaService) {}

  findActive(): Promise<User[]> {
    return this.prisma.user.findMany({ where: { isActive: true } });
  }
}

Обрати внимание, чего нет: ни forFeature, ни токена repository, ни декоратора на модели. Вся поверхность API — это this.prisma.<model>.<operation>, а тип User приходит из @prisma/client, регенерируясь каждый раз при изменении схемы.

Настоящее решение: где живёт истина

Когда оцениваешь эти варианты в реальном PR, аргументы о вкусе быстро перестают иметь значение — ограничения не перестают. Ни один не верен универсально — они различаются по трём осям, которые сеньор взвешивает против заявленного ограничения. Источник истины для типобезопасности — первая: entity-классы с декораторами TypeScript (TypeORM) против .prisma-схемы, которая генерирует клиент (Prisma). Миграции вытекают из этого: TypeORM генерирует и прогоняет файлы миграций, выведенные из твоих entities; Prisma Migrate сравнивает схему и выдаёт SQL-миграции. И эргономика DI расходится: TypeORM даёт per-entity repository как первоклассные провайдеры Nest; Prisma даёт один клиент, который ты оборачиваешь и инжектишь повсюду.