리팩토링 3 - JPA 추상층 변경

 

JPA

현재 문제

 

 

 

이와 같이 , 기본적인 기능만 (따로 선언하지 않아도 되는) 사용하는 JPAREPOSITORY에 대한 리뷰를 받았다.

 

왜 이런 형태는 단점이 있을까?

출처: https://velog.io/@seongwon97/Spring-Boot-%EC%98%81%EC%86%8D%EC%84%B1-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8Persistence-Context

 

JPA의 구조:

JPAREPOSITORY를 사용한다는 건,  영속성 컨텍스트를 이해 해야 한다.

 

영속성 컨텍스트 (PERSISTENCE CONTEXT):

ENTITY를 영구 저장하는 환경

APPLICATION과 , DATABASE 사이에서 객체를 저장하는 가상의 DB가된다. 

(키:밸류 형태의 해시를 활용해, 조금 더 빠르게 사용하게 돕는다)

FLUSH를 통해 실제 DB에 저장한다.

 

ENTITY MANAGER:

이 영속성 컨텍스트를 관리한다. 엔티티를 저장하고 관리한다.

 

고민

JPAREPOSITORY를 활용한다는 건, 수많은 기능과 영속성 컨텍스트를 활용한다는 것이다. 그럴 필요가 있을까? 

 

가장 먼저, JPA를 활용하였기 때문에 자연스럽게 메모리를 사용하게 될 것이다. 

또한, JPA는 상위의 CRUD REPOSITORY와 같은 모든 내용을 상속하는 REPOSITORY이기 때문에 그 중에서도 가장 크다. 이러할 가치가 있을까 고민해보았다.

 

결론

영속성 컨텍스트는 사용하자. 

 

JPA를 아예 사용하지 않으려면, JDBC를 사용해야 한다. 

하지만 JDBC를 사용하게 되면, CONNECTION 관리 그리고 수많은 코드 관리를 진행해야 한다. 

또한 SQL 쿼리를 직접 삽입하기 때문에, SQL INJECTION에도 치명적인 모습을 보인다.

 

최대한의 경량화를 진행하자.

 

최소한의 기능만 구현한 Repository

 

기존 JPAREPOSITORY를 확장하던 모델에서, 내가만든 REPOSITORY를 확장

기존 가능했던 method들이 모두 사라졌음을 확인

 

테스트 성공!

 

이와 같이 진행하여 다음과 같은 장점을 얻었다.

 

1. 원하지 않은 METHOD 들의 생성 해결

2. REPOSITORY 부 경량화 

3. REPOSITORY명을 보아도, 다른 개발자가 JPA영역에선 어떤 일이 이루어지는지 한눈에 볼 수 있다.

 

 

 

다음은, 세부 코드 들에 대해서 리팩토링을 진행해 보도록 하겠다.