[TIL]TypeORM 개념

영태·2022년 4월 2일

[TIL]

목록 보기

11/21

TypeORM

javascript 지원 데이터베이스를 사용하는 모든 응용 프로그램에서
코드 객체를 데이터베이스 언어(SQL)와 일치시켜주는 도구다
즉 우리가 만든 객체에 따른 SQL을 자동 생성해서 동기화시키는 일을 한다

ORM

object relational mapping의 약자
객체(class)와 테이블 시스템(RDBMSs)을 연결해주는 작업.

객체 지향 프로그래밍(java, C, javascript 등)는 클래스 방식을 사용한다
한편 관계형 데이터 베이스는 테이블 방식을 사용한다.
사용하는 코드의 타입도 다르다
이 지점에서 객체 모델과 관계형 모델간의 불일치가 존재하게 된다

이 불일치를 서로간의 관계를 바탕으로 SQL을 자동 생성하여 해결하는 것이 바로 ORM이다

ORM을 이용한 개발은 객체와 데이트베이스의 수정에 유연하게 대처할 수 있도록 해준다.
객체 지향 프로그래밍 관점에서 보면, 관계형 데이터베이스에 최대한 제약받지 않으면서 객체처럼 쉽게 표현하고 사용하는 것을 말한다

장점

객체 지향적 코드로 인해 더 직관적이다
- CRUD을 위한 긴 SQL문장을 작성할 필요가 없다
- 각 Model 별로 코드를 작성하여 가독성이 높다
- SQL의 절차적 접근이 아닌 객체적인 접근으로 생산성을 높여 준다
재사용 및 유지보수의 편리성이 증가한다
- 매핑 정보가 명확하다. ERD에 대한 의존도를 낮출 수 있다
- ORM은 독립적으로 작성이 되어 있고 재사용이 가능 하다.
DBMS에 대한 종속성이 줄어든다
- 대부분의 ORM은 DB에 종속적이지 않다
- 개발자는 Object에 집중함으로 DBMS를 교체하는 극단적인 작업에도 비교적 적은 리스크와 시간이 소요된다.
- 종속적이지 않다는 것은 구현 방법 뿐만 아니라 많은 솔루션에서 자료형 타입까지 유효하다.
  (*종속성: 프로그램 구조가 데이터 구조에 영향을 받는 것을 의미함

단점

완벽한 ORM은 구현하기가 어렵다
- 사용하기 편하지만 초기 설계에 매우 신중해야 한다.
- 프로젝트의 복잡도가 높을 경우 난이도 또한 높아진다
- 잘못 구현된 경우 속도 저하, 심한 경우 일관성이 무너진다
프로시저(특정작업을 위한 프로그램의 일부)가 많은 시스템에서는 ORM의 객체 지향적인 장점을 활용하기 어렵다
- 이미 프로시저가 많은 시스템에서는 데이터베이스 언어를 다시 객체로 바꿔야하는 경우가 생기며 생산성 저하로 이어진다

TypeORM은 다음과 같이 사용한다
이를 export해서 다른 ts확장자 api파일에서 import하여 사용한다

entity 파일은 api 폴더 안에 다른 ts파일들과 함께 저장한다
보면 추가로 붙는 요소가 바로 @Entity라는 녀석이며
이 파일 또한 ~.entity.ts로 명시되어있다

Entity에 대해서 알아보자

Entity

흠...실체..존재 라고 되어있다

TypeORM Docs에 따르면
Entity는 데이터베이스 테이블(또는 MongoDB를 사용하는 경우 컬렉션)에 매핑되는 클래스다.
Entity를 작성하려면 새 클래스를 정의하고 @Entity()로 마킹하면 된다

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

@Entity()
export class User {

    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    firstName: string;

    @Column()
    lastName: string;

    @Column()
    isActive: boolean;

}

이렇게 만든 클래스에
1. 열의 내용에 들어갈 type을 지정해준 후
2. @Column을 이용해 열로 명시해준다

그럼 데이터베이스의 table의 열이 하나 만들어지는 원리다

이 Entity의 종류는 당연히 @Column 만이 아니다
하나씩 확인해보자

1. @PrimaryColumn()

모든 유형의 값을 포함하는 프라이머리 열을 만든다.

열 유형을 지정할 수 있으며 지정하지 않으면 속성 유형에서 유추된다.
예를 들어 number인 경우 Int형으로 자동 유추한다

2.@PrimaryGeneratedColumn()

이 컬럼은 자동 증분 값으로 값이 자동으로 생성된다. 자동 증분/시리얼/시퀀스/아이덴티티를 사용하여 int 열을 만듭니다(제공된 데이터베이스 및 구성에 따라 다름). 자동으로 값이 생성되기 때문에 저장하기 전에 값을 수동으로 할당할 필요가 없다.

3.@PrimaryGeneratedColumn ( "uuid")

Uuid로 자동 생성되는 기본 열을 만든다. Uuid는 고유한 문자열 ID다. 저장하기 전에 값을 수동으로 지정할 필요가 없습니다.값이 자동으로 생성됩니다.

4. Special columns

사용할 수 있는 추가 기능이 있는 몇 가지 특수 열 유형이 있다.

@CreateDateColumn은 엔티티의 삽입 날짜에 자동으로 설정되는 특수 열이다. 이 열은 자동으로 설정되기에 설정할 필요가 없다.

@UpdateDateColumn은 엔티티 관리자 또는 저장소의 저장을 호출할 때마다 엔티티의 업데이트 시간으로 자동 설정한다. 마찬가지로 자동으로 설정되기에 설정할 필요가 없다.

@DeleteDateColumn은 엔티티 관리자 또는 저장소의 소프트 삭제를 호출할 때마다 엔티티의 삭제 시간으로 자동 설정됩니다. 마찬가지로 자동으로 설정되기에 설정할 필요가 없다. @DeleteDateColumn이 설정되어 있는 경우 기본 스코프는 "non-delete"가 된다.

@VersionColumn은 엔티티 매니저 또는 저장소의 저장을 호출할 때마다 자동으로 엔티티 버전(증분 번호)으로 설정됩니다.마찬가지로 자동으로 설정되기에 설정할 필요가 없다.

마치며

성능 상으로는 무조건 좋은 선택지는 아니지만 TypeORm은 SQL 구문을 통한 최적화도 지원해주고 있기 때문에 메리트가 있는 도구다.

개인적으로 이해한 바로는 객체 모델과 분리시켜서 entity 파일을 만들고 이를 database용으로 사용할 수 있게끔 해주는 도구라고 생각했다. 이를 통해 구조도 편하게 확인할 수 있고 유지 보수도 더 깔끔해진다고 본다.

또 이렇게 entity파일을 분리시켜 사용할 때 이를 graphql과 연동하여 사용하면 본문에서의 코드가 길어지는 경우도 막을 수 있고 꿩(typeorm)먹고 알(graphql)먹고 할 수 있어 이런 방식을 사용하지 않을 이유가 없다고 생각한다