repository 패턴 개념

기존에 작성한 코드들은 service에서 비즈니스 로직(db를 조작하는 로직)을 담당했지만 repository라는 하나의 layer를 하나 더 두어서 repository에서 비즈니스 로직을 담당하는 함수를 작성하고 service에서는 repository에서 작성한 함수를 호출하는 패턴이다.

repository 패턴을 사용하는 이유

가장 큰 이유는 유지보수 때문이다. 내가 현재 프로젝트에서는 mongoDB를 사용해서 로직을 작성했지만 나중에 dynamoDB로 변경해야할 일이 생긴다면 기존 service에서 비즈니스 로직을 다 처리하는 부분을 다 바꾸어야 하지만 repository 패턴을 사용하면 호출되는 함수의 비즈니스 로직을 바꾸어주면 된다. 이렇게 결합도를 낮추어 애플리케이션의 다른 부분에 미치는 영향을 최소화할 수 있다.

repository 내용

위 개념만 보면 아직 감이 안잡힐 수 있다. 코드를 보며 확인해보자!

cats.repository.ts

import { HttpException, Injectable } from '@nestjs/common';
import { InjectModel } from '@nestjs/mongoose';
import { Cat } from './cats.schema';
import { Model } from 'mongoose';
import { CatRequestDto } from './dto/cats.request.dto';

@Injectable()
export class CatsRepository {
  constructor(@InjectModel(Cat.name) private readonly catModel: Model<Cat>) {}

  async existsByEmail(email: string) {
    try {
      const result = await this.catModel.exists({ email });
      return result;
    } catch {
      throw new HttpException('db error', 400);
    }
  }
  async create(cat: CatRequestDto) {
    return await this.catModel.create(cat);
  }
}

위 코드는 새로 만든 cats.repository.ts 파일이다.

이 파일에서는 기존 mongoDB의 데이터를 조작하는 로직을 service에서 떼어내 가져왔다. 그리고 해당 로직을 처리하는 부분을 함수로 만들어서 결합도를 낮춰 유지보수를 쉽게 만들었다. 나중에 에러를 고칠 때도 existsByEmail, create 로 함수들이 나누어져 있어 에러가 난 곳을 쉽게 찾아내고 수정할 수 있다.

repository를 결합한 service

기존 service 또한 repository 패턴을 통해 많이 달라지게된다. 일단 비즈니스 로직 담당하는 코드들이 repository로 이관됨에 따라 repository에서 작성된 함수를 불러와서 활용하는 방식으로 코드들이 작성된다.