[NestJS][TypeORM] Data Mapper Pattern

학습 키워드

• Data Mapper Pattern: 객체와 데이터베이스 간의 매핑을 책임지는 중간 계층
• Repository: 데이터 접근을 관리하는 클래스
• ORM (Object-Relational Mapping): 객체와 관계형 데이터베이스 간의 매핑
• 분리된 책임: 데이터와 비즈니스 로직의 분리
• 유지 보수성: 대규모 애플리케이션에서의 효율성

 

학습 정리

Data Mapper Pattern이란?

**Data Mapper Pattern**은 객체와 데이터베이스 간의 매핑을 담당하는 중간 계층이다.

이 패턴은 데이터 접근 로직과 비즈니스 로직을 분리하여 유지 보수성과 확장성을 높이는 것을 목표로 한다.

즉, 엔티티 객체는 데이터의 구조를 표현하며, 실제 데이터베이스와의 상호작용은 리포지토리나 매퍼에서 수행한다.

백엔드 개발하면서 Repository를 만들어서 관리하던게 기억나는 순간이었다. 이게 다 Data Mapper Pattern이었다.

 

 

주요 특징

• 데이터와 비즈니스 로직의 분리: 데이터베이스와의 상호작용은 매퍼(또는 리포지토리)에서만 수행되며, 엔티티 객체는 데이터 자체만을 표현한다. 이렇게 함으로써 비즈니스 로직과 데이터 접근 로직을 명확히 분리한다.
• Repository 클래스: 데이터베이스와 상호작용하는 로직을 포함하는 클래스이다. 비즈니스 로직에서 이 리포지토리를 통해 데이터를 읽고 쓰기 때문에, 데이터 접근을 더욱 체계적으로 관리할 수 있다.

 

예시 코드

// **User 엔티티**
import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm';

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

  @Column()
  name: string;

  @Column()
  email: string;
}

위 User 엔티티는 단순히 데이터의 구조만을 나타낸다. 데이터베이스와의 직접적인 상호작용 로직은 포함되지 않는다.

이건 Entity 객체로 DB를 접근하는 Activate Record Pattern과 다른 점이다.

// **UserRepository(리포지토리)** 파일을 생성해서 DB 접근
import { EntityRepository, Repository } from 'typeorm';
import { User } from '../entities/user.entity';

@EntityRepository(User)
export class UserRepository extends Repository<User> {
  async findByEmail(email: string): Promise<User | null> {
    return await this.findOne({ where: { email } });
  }
}

위 UserRepository는 데이터 접근 로직을 관리한다.

비즈니스 로직은 별도의 서비스 클래스에서 처리하며, 데이터 접근이 필요할 때는 이 리포지토리를 사용한다.

// **UserService (서비스 클래스)**
import { Injectable } from '@nestjs/common';
import { UserRepository } from './repositories/user.repository';

@Injectable()
export class UserService {
  constructor(private userRepository: UserRepository) {}

  async getUserByEmail(email: string) {
    return this.userRepository.findByEmail(email);
  }
}

UserService는 비즈니스 로직을 담당하며, 데이터 접근을 위해 UserRepository를 사용한다.

 

Data Mapper Pattern의 장점

• 유지 보수성: 비즈니스 로직과 데이터 접근 로직이 분리되어 있으므로 각각 독립적으로 관리 및 수정이 가능하다.
• 모듈성: 데이터 접근에 대한 변경이 필요할 때 엔티티나 비즈니스 로직에 영향을 주지 않으므로, 모듈 간 결합도가 낮다.
• 테스트 용이성: 데이터 접근과 비즈니스 로직이 분리되어 있어 단위 테스트를 더 쉽게 수행할 수 있다.

 

Data Mapper Pattern의 단점

• 초기 복잡도: 코드 구조가 복잡해질 수 있으며, 여러 계층(엔티티, 리포지토리, 서비스 등)을 추가로 작성해야 하기 때문에 소규모 프로젝트에서는 불필요한 복잡성을 초래할 수 있다.
• 코드의 양 증가: 비즈니스 로직과 데이터 접근 로직의 분리로 인해 계층이 많아지며, 코드의 양이 증가한다.

 

Data Mapper Pattern과 활성화 기록 패턴의 비교

• 활성화 기록 패턴:
  • 엔티티가 데이터베이스와 직접 상호작용한다.
  • 단순한 CRUD 중심의 애플리케이션에서 유용하다.
  • 비즈니스 로직과 데이터 접근 로직이 결합되어 있어 유지보수가 어려울 수 있다.
• 데이터 매퍼 패턴:
  • 엔티티와 데이터 접근 로직을 분리하여 유연성과 유지 보수성을 높인다.
  • 복잡한 비즈니스 로직을 가진 대규모 애플리케이션에서 유리하다.
  • 테스트 가능성이 더 높고, 비즈니스 로직과 데이터 접근이 명확히 구분된다.

 

참고 자료

• https://docs.nestjs.com/recipes/sql-typeorm#repository-pattern
• https://typeorm.io/active-record-data-mapper