TIL-221102 jpa보다는 프로그래밍에 비중을

오늘은 또 다시 모델들을 갈아 엎으면서 구조를 바꾸었다. 원래 처음 사용했던 구조로 다시 원점으로 돌아왔다.

리팩토링을 한 후 Product 모델이 가지고 있는 속성값들인데 Product와 OneToMany관계에 있는 이미지나 리뷰 문의 같은
같은 컬렉션 객체들은 Product모델의 속성값들에서 다시 뺴면서 다이어트를 해주었다.

OneToMany, ManyToOne jpa어노테이션을 사용한 이유는 오히려 DB구조에 대해서 의식을 하고 만드는 것이 아닐까?
라는 고민이 들어서 OneToMany를 사용해서 Product가 다른 도메인 모델을 Collection으로 가지고 있게 만들었는데
이렇게 되면 상위 컴포넌트가 하위 컴포넌트를 볼 수 있는 관계인데 조금 이상한 관계이지 않은가 싶다.

하지만 Collection을 가지고 있지 않으면 상위 모델은 다른 모델을 신경쓸 필요가 없고 객체간의 협력을 적극적으로 권장하는
형태가 되는 것 같다.

그리고 OneToMany와 ManyToOne을 사용할 때는 PostDto가 이미지나 리뷰 같은 모델의 컬렉션을 그대로 가지고 있는 구조 였는데
이제는 컨트롤러에서 DTO로 모델들을 변환한 후 통신을 할 수 있게 됬다.

모델의 getter에 get~~ 라는 형식으로 쓰는 게 마음에 안 들었는데 get~형식으로 사용하지 않아도 되니까 좋다.

OneToMany를 사용하는 것보다 테스트하기도 더 쉬워진 느낌이고 재미있기도 하다 우리모두 jpa에 의존하지 않고 모델을 만들어봅시다.

jpa에 의존하지 않고 객체지향적으로 모델들을 협력 관계로 만들어 보자

오늘은 전체적으로 다시 jpa에 의존하지 않고 모델들을 리팩토링하는데 시간을 쓰느라 장바구니 기능에 추가하는 것 까지 밖에
하지 못했다.

장바구니는 생각보다 구현이 재미있을 것 같다. CRUD가 모두 들어가 있는 구조인데 CRUD의 C는 만들었으니까
내일은 장바구니를 완성하는 것 까지 목표로...



장바구니의 모델을 설계하는 과정에서 조금 의문이 든 것이 있다. CART와 CARTITEM이라는 객체를 사용할려고 했는데
굳이 CART가 있어야 할까?

CARTITEM이 userID를 가지고 있으면 Repository에서 찾아서 주면 굳이 CART라는 모델이 필요가 없는데 하지만
만들어 줬다.

소프트웨어세계와 현실세계가 같다고 할 수 는 없지만 어쨌든 고객은 쇼핑몰에서 고객은 장바구니를 들고 있는 것이 당연하기 떄문?