Product DataAccess 계층 개발 시작

이번 7월 2째주는 정말 시간을 소중하고 효율적으로 사용하지 못한 것 같다. 매일 하루를 돌이켜보면 고민만 하는 시간이 점점 더 많아지는 것 같기도하다.. 그리고 무엇보다 하루 10시간의 코딩 몰두를 잊어가는 것 같다. 편한마음으로 임하는 이 태도.. 고쳐먹어야겠다.

---

Product DataAccess

 

오늘부터 나는 본격적으로 Product DataAccess 를 구현하기 시작했다. 영속성 계층을 개발하는데 있어 지난 Member 와 진짜 다를 것이 없어, 익숙치 않은 JPA Entity를 생성하는 것 외에는 크게 어렵지 않을 것 같다. 그래서 나는 이전에서 좀 더 나아가보려고한다.

 

나는 Querydsl 을 추가적으로 JPA 와 함께 사용해보려고한다. Querydsl을 사용하려고 하는 이유는, JPA(JPQL)의 문제점(?) 한계 때문이다. 얼마 사용해보지도 않은 놈이 무슨 벌써 한계를 이야기한다니, 웃기다. 근데 책과 지난 강의를 보면서 바라본 JPA는 지금 내 상황에서 편리하면서 불편할 것 같다.

 

지금 내 모델링은 불완전하다. 필드가 계속해서 추가되거나 삭제되거나 명칭이 바뀔 수 있다. 근데 만약 해당 필드를 사용하는 쿼리가 있다면? 전부 다 수정해야할 것이다. 즉 코드변경에 너무 취약하다. 그리고 메서드 작명이 너무 싫다.... findBy... (진심으로 Bye 하고싶다...) 조건이 추가되는 쿼리를 작성한다고하면, 강제로 findByBAndC... 너무 별로다.... 무엇보다 가장 싫은 이유는 쿼리를 문자열로 작성한다는 것이다. 나는 지난 담당했던 프로젝트에서 쿼리를 모두 문자열로 작성했다. 이게 왜 싫냐면, 오타, 띄어쓰기와 같은 잦은 실수 때문에 에러가 발생하는 경우가 많았기 때문이다. 이는 내가 실수를 안하면되지만, 실수를 하고싶어서 하는 것이 아니기에.. 최대한 이런 문제를 줄이고 싶고 querydsl 은 이 문제를 해결할 수 있다. 추가적으로, 공부해본 내용으로는 Spring Data JPA는 일반적인 쿼리 작성과는 약간의 문법의 차이가 존재한다. 그래서 복잡한 쿼리를 작성한다면, 그 때마다 찾아봐야한다.(나처럼 초급자는 아마 정말 계속 찾아보지 않을까 싶다.)

 

근데 이를 어떻게 Querydsl 이 가능하게 해준다는 것일까? 정말 간단하다. 쿼리를 코드로 작성할 수 있도록 만들어주기 때문이다. 그래서 나는 querydsl 도 추가하기로 마음 먹었다.

 

주목해야할 점으로 나는 Querydsl 을 추가한다는 것이지, 아예 JPA를 대체한다는 것은 아니다. 분명 JPA는 편리하다. CRUD 가 기본적으로 구현되어있기에 너무나도 편리하다. 근데 또 불편하다. 그리고 이 불편함을 Querydsl 을 통해 보완할 수 있다하는데, 안쓸이유가 있을까?

 

현 프로젝트에서 Repository에 대한 이야기를 간단하게 해본다면, Repository는 도메인 계층이 영속성 계층에 의존하던 관계를 뒤집어 주는 역할이며, Concrete Repository 는 영속성 어댑터로 이야기 할 수 있다.

 

도메인 계층과 영속성 계층의 관계도

 

 오늘 나는 JPA Entity를 구현했다. 영속성 어댑터까지 구현을 하고 싶었는데, 생각보다 JPA와 Querydsl 을 어떻게 해야 둘다 하나의 영속성 어댑터에서 사용할 수 있을지 구성에 대한 고민때문에 머리가 아프다.

 

---

하나의 JPA Repository

하나의 JpaRepository를 통해 사용하는 방법

나는 첫번째 방법으로JPARepository하나로 Querydsl 을 추가하는 방법을 생각했다. 하지만 이는 뭔가.. 나 Querydsl 사용하고있어! 라고 외치는 것 같지 않았다. 하나로 간편하게 해당 기능을 사용할 수 있지만, 개인적으로는 외침이 부족하다 판단하여 탈락.

 

 

 

---

의존성 주입 방법

 

 

다음방법으로는 Querydsl을 bean 으로 등록하고, 영속성 어댑터에 의존성을 주입하여 사용하는 것이다. 이를 사용하면, 너무나도 나 Querydsl 사용하고있어!! 를 외치고 있는 모습을 띈다. 아주 맘에든다. 나는 이걸 사용할 것이다.

 

 

 

나는 Impl 클래스를 또 다시 만들어야한다.

하지만 고민은 끝나지 않는다.  바로 구현체를 사용할 것인가, 혹은 기존의 방식대로 인터페이스와 해당 구현체를 사용하며, 인터페이스를 사용할 것인가?

 

나는 영속성 계층과 관련하여 개발을 진행하면서. 기능을 추가할 때마다 인터페이스를 수정하고, 구현클래스를 수정하는 것이 익숙치 않다. 사실 이게 맞는것인지 모르겠다. 구현체가 아닌 인터페이스에 의존해야한다는 것은 알고 있는데, 이렇게 하는 것이 맞는건지 모르겠다. 이게 트레이드 오프인가? 하는 생각이 들기도하고.. 관련해서 이야기를 나눠보고싶은데, 주변에 스프링 JPA 를 사용하는 개발자 분들이 없어, 이 이야기를 어떻게 해야할지 모르겠다.

 

그래서 나는 고민이다. 혼자만의 고민.. 어떻게 이야기를 할 수 있을까에 대한 고민... 어렵다 어려워...

 

---

오늘은 고민과 구현, 중간단계에서 왔다리 갔다리 했다. 했다가 아닌것같아 되돌리고.. 고민하고.. 다시하고.. 그랬다.. 오후에는 코딩테스트 관련한 세션(?)이 있어서 들어보았는데, 역시 코테는 전략적으로 가야겠다.. 근데 지금은 코테보다는 이런 설계적인 고민이 너무 재밌다... 근데 또 코테로 문제풀이 능력과 자료구조를 공부하고싶다... 하고싶은건 많아지는데, 이번주말과 다가오는 날들은 시간을 정말!! 알차게!!! 잠을 다시 6시간(+40분)씩 자면서.. 해야겠다.. 할 수 있다!!!!! 아좌좌~~~!