프로젝트의 전반적인 리팩터링을 다시 시작하며, 기존 mybatis를 이용했던 것을 그대로 옮겨왔다.
하지만 SQL Mapper를 이용한 설계 특성상 객체 지향적인 코드의 작성이 어려웠고, 또 기존 DB 설계의 문제도 있다는 것을 알게 되었다.
DB의 전반적인 수정과 더불어, JPA를 이용해 다시 리팩터링을 해보기로 결정을 내렸다.
그 수정과정과 JPA 세팅 방법을 나열해보겠다.
https://github.com/GroovyArea/My-ChickenBreast-Shop
SQL Mapper 기존 문제점
기존에는 Mybatis를 이용해 프로젝트를 2개 진행했었다.
DB와 연동하기 위한 모든 쿼리를 직접 작성해야 하기 때문에, SQL을 작성하는 연습을 하는 데는 도움이 되었던 것 같다.
13절의 쿼리에서 VO를 리턴 받고 값의 변경이 일어날 경우 다시 저장하게 되는 경우가 있다고 치자.
VO는 Setter가 없으므로, 다시 생성자를 이용해 변경된 객체를 생성하거나, 컨트롤러에서 파라미터로 받아와서 수정을 해야 될 것이다.
또 자연스레 SQL 에 의존적인 개발을 하게 될 것이므로, 매퍼에 기반한 로직을 작성하고 흐름을 이끌어 나갈 수밖에 없다.
객체지향적인 구조와 멀어지게 되는 것이다.
좀 더 유지보수가 쉽고 수준 높은 코드를 작성하고 보다 객체지향적인 코드를 작성해보고 싶은 생각이 있어서 이 참에 JPA를 이용해서 리팩터링을 해보기로 결심했다.
> JPA 세팅
JPA 세팅은 뭐 별거 없다.
Spring boot starter JPA를 추가하고,
application.properties에 기본적인 jpa 설정들을 추가하면 끝이난다.
너무 쉽기 때문에, 따로 정리하진 않겠다.
참조 : https://blog.jiniworld.me/129
> javax 기본 애노테이션을 사용해서 연관관계도 설정해주고.
연관관계를 개발 초기 단계에서 미리 하지 말고, 필요한 경우에 맺어주자~
DB 수정
기존 ERD
- DB 자체의 정해진 컨벤션도 없이 없다.
- 카카오페이 외부 API에 의존적인 칼럼이 존재한다.
- 전반적인 주문 프로세스의 테이블 구성이 잘못되었다.
수정 ERD
- pk의 컨벤션을 지키며 수정해보았다.
- Amount 테이블은 DB에 저장할 이유가 없기에 삭제했다.
- Product 레코드의 데이터가 수정될 경우 주문한 상품의 데이터도 수정되기 때문에 이를 방지하고자 중계 테이블을 생성했고, 주문 당시 상품의 스냅숏 데이터까지 보관했다.
- 데이터의 수정 및 조회를 원활하게 하기 위해 생성, 수정 시각 칼럼을 추가했다.
참조 : https://techblog.woowahan.com/2591/
반응형
'📕 Spring Framework > Spring Project' 카테고리의 다른 글
동시성 조회 문제 해결 및 성능에 관한 고민 [Lock, Queue, Redis] (0) | 2022.09.14 |
---|---|
객체 간 매핑을 위한 MapStruct 사용 방법 (0) | 2022.08.29 |
코드 리팩토링 [1] (0) | 2022.08.03 |
리팩토링 계획 (0) | 2022.07.28 |
리팩터링 「Authentication(인증)」 (0) | 2022.07.11 |