Skip to content

[JPA study 5주차 이해림]

Haerim Lee edited this page May 13, 2024 · 2 revisions

SECTION 6

1) 주문, 주문상품 엔티티 개발

제일 중요 비즈니스 로직들이 얽혀서 어떻게 작동되는 지 알 수 있어서

   public static Order creatOrder(Member member, Delivery delivery, OrderItem... orederItems){
       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;
// 오더가 연관관계를 걸면서 세팅이 됨.(상태와 주문시간까지) 정리 유용.
이러한 스타일이 중요한 이유 생성하는 지점을 변경할  'creatOrder'이것만 바꾸면 .
this.setStatus(OrderStatus.CANCEL);
       for(OrderItem orderItem: orderItems) {
           orderItem.cancel();
       }
// 만약 고객이 오더를 두번하면 오더아이템이 두 개 생성 그렇기에 취소할 땐 각각 캔슬을 날려줘야 함.
public void cancel() {
       getItem().addStock(count);
   }
// 캔슬하면 일단 재고가 없다는 경우가 있으므로 재고를 채워줘야 함. 

   public int getTotalPrice() {
       int totalPrice = 0;
       for (OrderItem orderItem : orderItems) {
           totalPrice += orderItem.getTotalPrice();
       }
       return totalPrice;
   }
// 토탈프라이스를 0으로 초기화 후 오더아이템으로 루프를 돌면서 오더아이템에 있느느 토탈프라이스를 가져옴 왜냐 주문할 떄 가격과 수량이 있으므로

3) 주문 서비스 개발

상품 주문할 때 상품의id만 넘어오게

orderRepository.save(order); 왜 이 한줄로만 세이브할까? 이유는 Order.java에 있는 caseade떄문 오더를 퍼시스트하면 모든 오더를 강제로 퍼시스트 딜리버리도 마찬가지 그래서 하나만 저장해줘도 오더와 딜리버리 둘 다 세이브가 된 거임!

참고로 OrderItem orderitem1 = new OrderItem(); 이런 식으로 개발하는 사람이 있음 그러나, 생성로직에서 필드를 넣거나 수정할 떄 매우 유지보수가 어려워짐. 분산되기에 그렇기에 이 외의 다른 스타일의 생성을 막아야 함.(protected 또는 @NoArgsConstructor(access = AccessLevel.PROTECTED))

@Transactional
   public void cancelOrder(Long orderId) {
       Order order = orderRepository.findOne(orderId)
       order.cancel();
   }
// 주문취소로직, 조회할 때에는 id만 가져옴. 로직이 매우 간단한데 비지니스 로직을 만들어서 배송완료된 것만 빼고 재고를 0으로 바꾸어 캔슬을 만들어 놓음. 여기서 JPA의 강점이 나옴. 지금 데이터를 변경한 것인데 밖에서 업데이트 쿼리를 직접만들어야 함 원래는 근데 jpa는 데이터만 바꾸면 알아서 바뀐 변경 포인트를 데이터베이스에 쿼리가 알아서 날아감 이런 경우는 오더의 데이터를 바꾼 것이기에 jpa 자체에서 오더 디비에 쿼리를 날려줄 것임.

비즈니스 로직은 대부분 엔티티에 있음 이런 스타일은 도메인 모델 패턴이라 칭함, 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할 엔티티는 비지니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 트렌잭션 스크립트 패턴이라 함.

4)주문 기능 테스트

아직 오류 수정 중,,, 추후에 추가하겠습니다!

Clone this wiki locally