23.01.30 TIL

☑️ 생성자에서 연관관계까지 처리하지 말자

// 생성자에 연관관계 편집 로직까지 넣은 경우(이렇게 사용 x)
public Order(User user, Item item) { 
this.user = user; // INSERT 
this.addItem(item); // flush 시 UPDATE 가능성 
}

 

문제	설명
단일 책임 원칙 위배	“객체 생성”과 “연관관계 변경”은 성격이 다름
불필요한 UPDATE 발생	영속성 컨텍스트 flush 시 INSERT → UPDATE 두 번 기록될 수 있음

 

권장: 연관관계 편의 메서드로 분리

@Entity 
public class Order { 

@ManyToOne 
private User user; 
@OneToMany(mappedBy = "order") 
private List<OrderItem> items = new ArrayList<>(); 

protected Order() {} // JPA 기본 생성자 

public Order(User user) { 
// 진짜 생성 책임만 
this.user = user; 
} 

// 연관관계 편의 메서드 
public void addItem(Item item, int qty) { 
OrderItem oi = new OrderItem(this, item, qty); 
items.add(oi); 
} 

}

---

☑️ DTO 변환 위치: 서비스 vs DTO 내부

 

전략	장점	단점
서비스 계층에서 for 루프	컨트롤러·DTO가 깔끔	서비스 코드가 장황해질 수 있음
DTO에 정적 팩터리 메서드	테스트·재사용 편리	DTO가 JPA 엔티티에 의존할 위험

 

-> 팀 컨벤션만 맞는다면 둘 중 뭘 사용해도 괜찮은 듯.. 단, 변환 로직이 길어지면 MapStruct·ModelMapper 등 매핑 툴을 고려하기!

 

---

☑️ 엔티티가 SQL 예약어와 충돌할 때

@Entity 
@Table(name = "orders") // 실제 테이블명만 변경 
public class Order { ... }

• 엔티티 클래스 이름은 도메인 용어(order) 그대로 유지
• 백엔드·프론트 코드 일관성을 깨지 않고도 “order” 예약어 문제 해결

---

☑️ 엔티티 코드 정렬 예시 (현재 우리 조 컨벤션)

1. 필드(컬럼) → 2. 생성자 → 3. 연관관계 필드 → 4. 연관관계 편의 메서드 → 5. 비즈니스 메서드
   -> 코드 리뷰 난이도 ↓ & 자동 정렬 플러그인과 충돌 최소화

---

☑️리스트? Page? Slice?

반환 타입	특징	언제 사용하는지
List<T>	쿼리 1회, 토탈 없음	“10개만 긁어오면 끝”
Page<T>	쿼리 2회 (SELECT + COUNT)	전체 페이지 수·총 건수 필요
Slice<T>	쿼리 1회 (COUNT 없음)	다음 페이지 존재 여부만 알면 충분할 때

Slice<Post> slice = postRepo.findTop20ByAuthorId( authorId, PageRequest.of(page, 20));

• 토탈 카운트 쿼리가 비싼 대용량 테이블이면 Slice 가 체감 차이를 보임
• 무한 스크롤 API (“다음 페이지가 있나?”)에 적합.