NestJS с TypeORM: при использовании пользовательского репозитория сервис больше не нужен? - PullRequest
Новая
       8

NestJS с TypeORM: при использовании пользовательского репозитория сервис больше не нужен?

0 голосов
/ 26 августа 2018

Вопрос новичка: при работе с NestJS и TypeORM, когда один создал собственный репозиторий (который расширяет стандартный репозиторий), нужен отдельный класс обслуживания?

ВВ настоящий момент я работаю только с пользовательским классом Repository, и он работает нормально, но я не уверен, что это правильно и, возможно, имеет некоторые побочные эффекты.

Кстати, в другом проекте у меня нет собственного репо, только сервис, который получает два стандартных репо, внедряется, и это тоже отлично работает.

С уважением,
sagerobert

1 Ответ

0 голосов
/ 27 августа 2018

Я думаю, что вам решать, насколько вы хотите добавить слои между typeORM и вашим самым «фронт-офисным» кодом (это были бы контроллеры в типичном приложении nest).

Я объясняю себе:

Если вы хотите, вы обычно можете напрямую встроить встроенные репозитории typeORM в свои контроллеры: 

import {Controller, Get} from '@nestjs/common';
import {InjectRepository} from '@nestjs/typeorm';
import {Repository} from 'typeorm';
import {User} from './entities/User.entity';

@Controller()
export class AppController {
    constructor(
        @InjectRepository(User)
        private readonly userRepository: Repository<User>,
    ) {
    }

    @Get()
    async root(): Promise<User> {
        return await this.userRepository.find(1);
    }
}

Так что это будет меньшеМногоуровневая реализация способа извлечения пользователя с ID = 1.

Теперь документация NEST рекомендует абстрагировать этот репозиторий и внедрить его в сервис, а не непосредственно в контроллер.Это позволяет вам меньше связывать между вашим контроллером и TypeORM.Вместо этого это ваш сервис, который имеет эту привязку.Если у вас есть много контроллеров, которые используют этот репозиторий, и вы решили, что хотите изменить TypeORM и использовать новый модный ORM, вам придется менять каждый контроллер.

Теперь, если вы просто внедрите репозиторий внутриваш сервис и используйте этот сервис на всех ваших контроллерах, вам просто нужно изменить реализацию вашего сервиса, и все контроллеры останутся прежними.

Во-вторых, представьте, что вы хотите протестировать свое приложение.Вы столкнетесь с той же проблемой.Как вы можете запустить свои тесты без подключения SQL?Я предполагаю, что ваши модульные тесты созданы не для проверки поведения TypeORM, а вместо этого написаны для проверки поведения вашего кода.

Гораздо проще смоделировать репозиторий, введенный в службу, чем макетировать все репозитории, внедренные в ваши контроллеры.

Итак, чтобы завершить этот ответ, я думаю, что этот вопрос должен быть закрыт, потому что онв первую очередь основано на мнении.Но ИМХО, воображаемая архитектура выглядит следующим образом:

  • Создайте пользовательский репозиторий, расширяющий репозиторий TypeORM.
  • Внутри пользовательского репозитория добавьте методы, использующие построитель запросов.
  • Внедрение этого пользовательского репозитория в ваши сервисы
  • Внедрение сервисов в ваши контроллеры.

Никогда не используйте построитель запросов в контроллерах, потому что его трудно издеваться.

Я надеюсь, что это ответ на ваш вопрос: Класс обслуживания не требуется.Но это поможет вам сохранить ваш код в чистоте.

...