[JPA 궁금증 모음/#1] Cascade REMOVE, int vs Integer, DTO 설계

#1 - Cascade = REMOVE, 언제 걸면 안 될까?

user ↔ review의 경우 review는 유저에게 종속되어있기 때문에 걸어도 된다.

하지만 user ↔ region의 경우 걸면 안된다.

 

user ↔ region의 경우 user가 region에 속한 구조이다.

즉 user가 region을 참조한다.

 

region은 여러 User에게 공유될 수 있다. (서울, 경기도 …)

예를 들어 서울 Region에 유저 a,b,c가 속해 있다 치자

유저 a가 삭제될 때 region도 cascade = REMOVE로 함께 지워지면,

서울 지역이 삭제된다. 그럼 다른 유저 b,c의 region은…? 사라진다. (문제 발생~)

비슷하게 카테고리와 같은 공용 테이블이 이에 해당한다.

 

 

#2 - int vs Integer 언제 써야 할까?

보통의 경우 Integer를 사용한다.

 

Integer를 써야 할 경우:

 

1. Null이 있을 때

• int는 primitive라 null을 표현할 수 없다고 함. (예: 포인트가 아직 부여되지 않았거나,)

2. Hibernate 내부 동작

• Hibernate가 엔티티를 관리할 때, Integer는 값이 설정되지 않은 것과 설정된 것(null 아님)을 구분할 수 있어서 더 유연하다.

3. DB 직접 컨트롤하고 싶을 때

• Hibernate 내부적으로 DDL 생성/추론할 때 primitive는 약간 애매하게 처리되기도 한다고 한다.
• Wrapper 타입(Integer)이 더 자연스럽다.
• @Column(columnDefinition = "INT DEFAULT 0") 같이 직접 DDL을 넣을 경우에 필요하다.

그렇다면 int는 언제?

해당 필드가 null일 수 없고, 기본 값이 분명한 경우 (예: review.rating 같이 1~5 범위가 명확한 경우)

 

 

#3 - 단일 DTO, 중첩 static DTO 방식 차이

무슨 차이일까~?

	단일 DTO 클래스	중첩 static DTO 클래스
구조적 단순성	단순하고 명확함	그룹핑되어 코드 정리가 잘됨
가독성	클래스 수 많아짐	관련 DTO를 하나의 outer class에 모을 수 있음
유지보수	파일 많아질 수 있음	한 파일에 관련 DTO들을 묶어 관리 가능
재사용성	클래스 단위로 쉽게 재사용	특정 context 안에 묶여서 독립적 재사용 어려움
의미 명확성	각각의 DTO가 명확한 이름으로 사용됨	컨텍스트(Join, Login 등) 분리 명확해짐

 

그렇다면 언제 어느걸?

 

• 단일 DTO 클래스 방식
  • 대부분의 CRUD API에 적합
  • 단일 기능/단일 목적일 경우
  • DTO 개별 관리와 테스트가 쉬움
• 중첩 static DTO 클래스 방식
  • 기능별(회원가입, 로그인 등)로 DTO가 여러 개 필요할 때
  • JoinDto, LoginDto, ProfileUpdateDto 등 묶어서 사용하면 가독성 증가
  • 특히 입력/출력 DTO가 많아질 때 패키지 or 파일이 너무 많아지는 것을 방지

 

그냥 중첩 static DTO 클래스를 쓰는 게 좋을 듯 하다..