<OrderItem의 필요성>
하나의 member는 N개의 order를 가질 수 있다.
1개의 order은 N개의 item을 가질 수 있다.
-> 주문과 아이템은 N:N관계이다. ->다대다 관계는 RDB에서 뿐만 아니라 ENTITY에서도 사용하지 않는 것이 좋다
-> OrderItem 이라는 엔티티를 추가해서 다대다 관계를 일대다 다대일 관계로 풀어낸다.
<OrderItem의 필요성 - Mybatis의 문제점>
OrderItem의 필요성에 기반하여 entity를 추가하게 되면
객체 지향적 관점에서 order entity는 여러개의 orderItem 리스트로 묶어서 가지고 있어야한다.
하지만 order entity가 List를 갖게 되면, mybatis입장에서는 이녀석을 그냥 db에 넣을 방법이 없다.
반복문을 돌려서 넣는다 하면 사실상 order table에 orderItem 요소들을 컬럼으로 갖는 single table 전략으로 table를 설계한것 과 동일하다. 즉, OrderItem의 필요성이 없어진다.
<OrderItem의 필요성> 하나의 member는 N개의 order를 가질 수 있다. 1개의 order은 N개의 item을 가질 수 있다. -> 주문과 아이템은 N:N관계이다. ->다대다 관계는 RDB에서 뿐만 아니라 ENTITY에서도 사용하지 않는 것이 좋다 -> OrderItem 이라는 엔티티를 추가해서 다대다 관계를 일대다 다대일 관계로 풀어낸다.
<OrderItem의 필요성 - Mybatis의 문제점> OrderItem의 필요성에 기반하여 entity를 추가하게 되면 객체 지향적 관점에서 order entity는 여러개의 orderItem 리스트로 묶어서 가지고 있어야한다. 하지만 order entity가 List를 갖게 되면, mybatis입장에서는 이녀석을 그냥 db에 넣을 방법이 없다.
반복문을 돌려서 넣는다 하면 사실상 order table에 orderItem 요소들을 컬럼으로 갖는 single table 전략으로 table를 설계한것 과 동일하다. 즉, OrderItem의 필요성이 없어진다.
말이 정리가 잘안됬는데, 생각을 좀더 해봐야할꺼 같고,
확실한건 mybatis를 사용하면 객체 지향적 설계는 상상속에서만 가능할것 같다.