본문 바로가기

기록하기

Day + 29


  • '실전! 스프링 부트와 JPA 활용 1 - 웹 애플리케이션 개발' 강의 내용 정리

  • 엔티티 설계시 주의점
    • 엔티티에는 가급적 Setter를 사용하지 말자
    • Setter가 모두 열려있다 -> 변경 포인트가 너무 많아서, 유지보수가 어렵다
  • 모든 연관관계는 지연로딩으로 설정
    • 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어려움
    • 특히 JPQL을 실행할 때 N+1 문제가 자주 발생
    • 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 함
    • 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용
    • 기본값이 즉시로딩인 관계는 -> 직접 지연로딩으로 설정
  • 컬렉션은 필드에서 초기화하자
    • 컬렉션은 필드에서 바로 초기화하는 것이 안전
    • null 문제에서 안전

  • 모든 엔티티는 기본적으로 persist를 다 저장하고 싶으면 각자 해줘야 함
  • (cascade = CascadeType.All) 활용하면 각각 해주지 않아도 됨
// 예제
@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
private List<OrderItem> orderItems = new ArrayList<>();

@OneToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
@JoinColumn(name = "delivery_id")
private Delivery delivery; //배송정보

 

  • 연관관계 (편의) 메서드 -> 양방향일 때 사용
// 예제
public void setMember(Member member) {
	this.member = member;
	member.getOrders().add(this);
}

public void addOrderItem(OrderItem orderItem) {
	orderItems.add(orderItem);
	orderItem.setOrder(this);
}

  • (예제에서) 주문 서비스의 주문과 주문 취소 메서드를 보면 비즈니스 로직 대부분이 엔티티에 있음. 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할을 함. 이처럼 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것을 도메인 모델 패턴 이라 함. 반대로 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 트랜잭션 스크립트 패턴 이라함
  • 강의에서는 도메인 모델 패턴이고, 내가 그동안 했던 과제는 트랜잭션 스크립트 패턴이었던 듯?

  • JPA 에서 동적쿼리를 어떻게 해결해야 되는가?
// JPQL 처리
public List<Order> findAllByString(OrderSearch orderSearch) {

	// language=JPAQL
	String jpql = "select o From Order o join o.member m";
	boolean isFirstCondition = true;
      
	// 주문 상태 검색
	if (orderSearch.getOrderStatus() != null) {
		if (isFirstCondition) {
              jpql += " where";
              isFirstCondition = false;
        } else {
              jpql += " and";
	}
          jpql += " o.status = :status";
      }
      
	//회원 이름 검색
	if (StringUtils.hasText(orderSearch.getMemberName())) {
    
          if (isFirstCondition) {
              jpql += " where";
              isFirstCondition = false;
          } else {
              jpql += " and";
	}
          jpql += " m.name like :name";
      }
      
      TypedQuery<Order> query = em.createQuery(jpql, Order.class) .setMaxResults(1000); //최대 1000건
      
      if (orderSearch.getOrderStatus() != null) {
          query = query.setParameter("status", orderSearch.getOrderStatus());
      }
     
     if (StringUtils.hasText(orderSearch.getMemberName())) {
          query = query.setParameter("name", orderSearch.getMemberName());
      }
      
      return query.getResultList();
  }

 

  • JPQL 쿼리를 문자로 생성하기는 번거롭고, 실수로 인한 버그가 충분히 발생 가능
// JPA Criteria 처리

public List<Order> findAllByCriteria(OrderSearch orderSearch) {

    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<Order> cq = cb.createQuery(Order.class);
    Root<Order> o = cq.from(Order.class); Join<Order,Member>m=o.join("member",JoinType.INNER);//회원과 조인
    List<Predicate> criteria = new ArrayList<>();
    
	//주문 상태 검색
	if (orderSearch.getOrderStatus() != null) {
          Predicate status = cb.equal(o.get("status"),
  	orderSearch.getOrderStatus());
          criteria.add(status);
      }
      
	//회원 이름 검색
	if (StringUtils.hasText(orderSearch.getMemberName())) {
          Predicate name =
                  cb.like(m.<String>get("name"), "%" +
  	orderSearch.getMemberName() + "%");
          criteria.add(name);
          }
          
        cq.where(cb.and(criteria.toArray(new Predicate[criteria.size()])));
		TypedQuery<Order> query = em.createQuery(cq).setMaxResults(1000); //최대 1000건
        return query.getResultList();
    }

 

  • JPA Criteria는 JPA 표준 스펙이지만 실무에서 사용하기에는 너무 복잡
  • 결국 다른 대안 필요 (-> 후에 학습 할 Querydsl)

  • 변경 감시와 병합(merge)
    • 엄청 중요! 꼭 이해하고 넘어가기!
  • 준영속 엔티티?
    • 영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말함
      • ex) 이미 DB에 한번 저장되어서 식별자가 존재. 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준영속 엔티티로 볼 수 있음
    • 준영속 엔티티를 수정하는 2가지 방법?
      • 변경 감지 기능 사용 (dirty checking)
        • 영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정
        • 트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 -> 트랜잭션 커밋 시점에서 변경 감지가 동작해서 DB에 Update SQL 실행
      • 병합(merge) 사용
        • 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능

  • 병합시 동작 방식 간단 정리
    • 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회
    • 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체(병합)
    • 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 DB에 Update SQL 실행
  • 주의?
    • 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경
    • 병합시 값이 없으면 null 로 업데이트 할 위험도 있음 (병합은 모든 필드를 교체)

'기록하기' 카테고리의 다른 글

Springboot + Docker + Github action  (0) 2023.11.15
Redis (1)  (1) 2023.11.15
배포 분투기(2)  (0) 2023.11.11
배포 분투기(1)  (0) 2023.11.11
Docker compose + Springboot + Mysql 연동하기(2)  (0) 2023.11.11