주문 repository, Service

1. OrderRepository

---

@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager em;

    public void save(Order order){
        em.persist(order);
    }

    public Order findOne(Long id){
        return em.find(Order.class, id);
    }

    //public List<Order> findAll(OrderSearch orderSearch){

    //}

}

 

2. OrderService

---

• 배송 주소는 간단하게 회원의 주소로 대체
• 다른 엔티티들은 save를 호출하지 않는데, order만 save를 했다? 왜???
• Cascade 옵션 때문! 
• OrderItem과 연관관계에 있는 엔티티를 모두 Cascade.All로 지정했다.
• 그렇다면 어느 범위까지 cascade를 지정해야 하나..?
  - order같은 경우 order가 delivery관리, orderitem관리..
  - orderitem과 delivery는 order만! 참조해서 씀 이런 경우에만 적용하자.
  - 즉 라이프사이클이 같은 엔티티만 적용

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;
    private final MemberRepository memberRepository;
    private final ItemRepository itemRepository;

    /**
     * 주문
     */
    @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);

        //주문 생성
        Order order = Order.createOrder(member, delivery, orderItem);

        //주문 저장
        orderRepository.save(order);
        return order.getId(); //cascade때문에 order만 persist해도 연관관계 같이 persist됨.


    }


    /**
     * 주문 취소
     */
    @Transactional
    public void cancelOrder(Long orderId){
        //주문 엔티티 조회
        Order order = orderRepository.findOne(orderId);
        //취소 --> 왜이리 간단함? 엔티티에 비즈니스 로직을 추가했음.
        order.cancel();
    }

    /**
     * 주문 검색
     */
//    public List<Order> findOrders(OrderSearch orderSearch){
//        return orderRepository.findAll(orderSearch);
//    }
}

 

 

* jpa 장점

데이터만 바꾸면 더티체크(변경내역 감지)를 해서 업데이트쿼리 날려줌. 캬...

SQL을 직접 다루면 업데이트쿼리 직접 날려줘야함.. ㅜ

 

 

3. 도메인 모델 패턴

---

(엔티티에 핵심 비즈니스 로직을 몰아넣는 스타일)

• 주문 서비스의 주문과 주문 취소 메서드를 보면
• 비즈니스 로직 대부분이 엔티티에 있다.
• 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할을 한다.
• 이처럼 엔티티가 비즈니스 로직을 가지고 객체 지 향의 특성을 적극 활용하는 것을
• 도메인 모델 패턴(http://martinfowler.com/eaaCatalog/ domainModel.html)이라 한다.
• 반대로 엔티티에는 비즈니스 로직이 거의 없고
• 서비스 계층에서 대부분 의 비즈니스 로직을 처리하는 것을
• 트랜잭션 스크립트 패턴(http://martinfowler.com/eaaCatalog/ transactionScript.html)이라 한다

 

4.GitHub : 210806 Order Service

---

GitHub - bsh6463/SpringBootJPA1