Advenced-JPA1-CH04

JPA Advance

Word count: 968Reading time: 6 min

 2023/06/27   Share

홈화면(thymeleaf)

DTO, Entity 는 반드시 분리하기 -> Entity는 완전 순수한 상태로만 쓰기
RestAPI 만들때는 Entity 절대 반환 금지 -> api 는 스펙이다. 엔티티가 계속 바뀌면 스펙이 바껴버림

변경 감지와 병합(merge)

em.save() 시에는
- Entity.getId() 값이 없는 것 -> em.persist()
- Entity.getId() 없는것은 em.merge() 가일어난다.

준영속 엔티티?
영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.
(여기서는 itemService.saveItem(book) 에서 수정을 시도하는 Book 객체다. Book 객체는 이미 DB 에 한번 저장되어서 식별자가 존재한다.(pk) 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준영속 엔티티로 볼 수 있다.)

한번이라도 과거에 DB에 갓다오면, 준영속이다. 하지만 지금은 JPA가 관리하지않고있다.
따라서 더티 체킹이 일어나지는 않는다.

준영속 엔티티를 수정하는 2가지

방법 변경 감지 기능 사용(같은 id 값을 같은 엔티티를 조회한다. -> 이때부터는 영속 엔티티다) (따로 update호출할필요없다)
병합( merge ) 사용

변경 감지 기능 사용

@Transactional
 void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티

Item findItem = em.find(Item.class, itemParam.getId()); //같은 엔티티를 조회한다.

findItem.setPrice(itemParam.getPrice()); //데이터를 수정한다. }

영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법
트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 트랜잭션 커밋 시점에 변경 감지(Dirty Checking) 이 동작해서 데이터베이스에 UPDATE SQL 실행

병합 사용

병합은 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능이다.

@Transactional

void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티 Item mergeItem = em.merge(itemParam);
}

병합 기존에 있는 엔티티

스크린샷 2023-06-27 오후 11.01.20

병합 동작 방식

merge()를실행한다.
파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.

2-1. 만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다.
조회한 영속 엔티티( mergeMember )에 member 엔티티의 값을 채워 넣는다. (member 엔티티의 모든

값을 mergeMember에 밀어 넣는다. 이때 mergeMember의 “회원1”이라는 이름이 “회원명변경”으로

바뀐다.)(따라서 transactional 끝날때 flush 가 일어날때, DB에 반영된다.)
영속 상태인 mergeMember를 반환한다.
주의할점은 param 으로 넣은itemParam은 영속되지않는다.
이후 transactional 끝날때 flush 가 일어날때, DB에 반영된다.

참고: 책 자바 ORM 표준 JPA 프로그래밍 3.6.5

병합시 동작 방식을 간단히 정리 (merge)(추천안하는이유)

준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한다.
영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다.(병합한다.)
트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE SQL이 실행

!!!주의: 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다. 병합시 값이 없으면 null 로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체한다.)

상품 리포지토리의 저장 메서드 분석 ItemRepository

package jpabook.jpashop.repository;

@Repository
     public class ItemRepository {
        @PersistenceContext
        EntityManager em;
        public void save(Item item) {
            if (item.getId() == null) {
                em.persist(item);
            } else {
                em.merge(item);
            }
          }

//...

}

save() 메서드는 식별자 값이 없으면( null ) 새로운 엔티티로 판단해서 영속화(persist)하고 식별자가 있으면 병합(merge)
지금처럼 준영속 상태인 상품 엔티티를 수정할 때는 id 값이 있으므로 병합 수행

새로운 엔티티 저장과 준영속 엔티티 병합을 편리하게 한번에 처리

상품 리포지토리에선 save() 메서드를 유심히 봐야 하는데, 이 메서드 하나로 저장과 수정(병합)을 다 처리한다. 코드를 보면 식별자 값이 없으면 새로운 엔티티로 판단해서 persist() 로 영속화하고 만약 식별자 값이 있으면 이미 한번 영속화 되었던 엔티티로 판단해서 merge() 로 수정(병합)한다. 결국 여기서의 저장(save)이라는 의미는 신규 데이터를 저장하는 것뿐만 아니라 변경된 데이터의 저장이라는 의미도 포함한다. 이렇게 함으로써 이 메서드를 사용하는 클라이언트는 저장과 수정을 구분하지 않아도 되므로 클라이언트의 로직이 단순해진다.

여기서 사용하는 수정(병합)은 준영속 상태의 엔티티를 수정할 때 사용한다. 영속 상태의 엔티티는 변경 감지(dirty checking)기능이 동작해서 트랜잭션을 커밋할 때 자동으로 수정되므로 별도의 수정 메서드를 호출할 필요가 없고 그런 메서드도 없다.

참고: save() 메서드는 식별자를 자동 생성해야 정상 동작한다. 여기서 사용한 Item 엔티티의 식별자는 자동으로 생성되도록 @GeneratedValue 를 선언했다. 따라서 식별자 없이 save() 메서드를 호출하면 persist() 가 호출되면서 식별자 값이 자동으로 할당된다. 반면에 식별자를 직접 할당하도록 @Id 만 선언했다고 가정하자. 이 경우 식별자를 직접 할당하지 않고, save() 메서드를 호출하면 식별자가 없는 상태로 persist() 를 호출한다. 그러면 식별자가 없다는 예외가 발생한다.

참고: 실무에서는 보통 업데이트 기능이 매우 제한적이다. 그런데 병합은 모든 필드를 변경해버리고, 데이터가 없으면 null 로 업데이트 해버린다. 병합을 사용하면서 이 문제를 해결하려면, 변경 폼 화면에서 모든 데이터를 항상 유지해야 한다. 실무에서는 보통 변경가능한 데이터만 노출하기 때문에, 병합을 사용하는 것이 오히려 번거롭다.

가장 좋은 해결 방법

엔티티를 변경할 때는 항상 변경 감지를 사용하세요
컨트롤러에서 어설프게 엔티티를 생성하지 마세요.
트랜잭션이 있는 서비스 계층에 식별자( id )와 변경할 데이터를 명확하게 전달하세요.(파라미터 or dto(파라미터많다면,전용 dto))
트랜잭션이 있는 서비스 층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하세요. 트랜잭션 커밋 시점에 변경 감지가 실행됩니다.

setXXX 를 직접 서비스 계층에서 쓰지말고, changeXXX() 쓰자!!!

엔티티에 따로 changeXXX를 정의해서 관련된 데이터를 한번에 데이터 update 하고 더티 체킹을 한느것이 매우좋다
- changeXXX 메서드 안에 관련된 필드 setXXX를 모아두자
set으로 각자하게되면 명확하지도 않다.

주문

계층적으로 풀어내는것이좋다

Controller

@PostMapping("/order")
public String addOrder(@RequestParam("memberId") Long memberId,
                       @RequestParam("itemId") Long itemId,
                       @RequestParam("count") int count) {

    orderService.order(memberId, itemId, count);
    return "redirect:/orders";
}

OrderService.java
- Service 계층에서 항상 엔티티를 다루고 Transactional 안에서 엔티티들 불려서 해결하자 -> 안전하다
- 비즈니스 로직은 Service 계층에서부터하자!!

//주문
  @Transactional
  public Long order(Long memberId, Long itemId, int count) {
      Member member = memberRepository.findOne(memberId);
      Item item = itemRepository.findOne(itemId);

      Delivery delivery = new Delivery();
      delivery.setAddress(member.getAddress());
      OrderItem orderItem = OrderItem.createOrderItem(item, item.getPrice(), count);

      // 주문 저장 -> 실제로 위에 연관관계에있는 모든 data save됨. cascade.all 옵션때문에
      // 어떨때 좋을까? order에서 delivery orderItem 모두 생명 주기가 같다. -> 다른곳에서 delivery를 가져다 쓰지않고 오직 order에서만 사용
      // 마찬가지로 OrderItem이 참조되는곳은 오직 order 한군대다. 이때 cascade.all이 적절하다
      Order order = Order.createOrder(member, delivery, orderItem);

      orderRepository.save(order);
      return order.getId();

  }

Order.java

// 생성메서드 -> 해당 객체와 관련된 생성은 해당 entity가 가짐. 자율화 캡슐화
public static Order createOrder(Member member, Delivery delivery, OrderItem... orderItems) {
    Order order = new Order();
    order.setMember(member);
    order.setDelivery(delivery);
    for (OrderItem orderItem : orderItems) {
        order.addOrderItem(orderItem);
    }
    order.setStatus(OrderStatus.ORDER);
    order.setOrderDate(LocalDateTime.now());

    return order;
}

Next Post

(핵심요약)스프링 부트와 JPA 활용2
Previous Post

Advenced-JPA1-CH03

CATALOG

1. 홈화면(thymeleaf)
2. 변경 감지와 병합(merge)
3. 주문
1. 3.1. 계층적으로 풀어내는것이좋다

