JPA Repository 상속을 받지 않는 이유

Spring Data Jpa를 사용하면 JpaRepository를 상속받아 쓸 수 있다.
이렇게 하면 간편하게 이미 만들어진 기능을 쉽게 사용 가능하다.

그런데 JpaRepository를 상속받지 않는 것에 대한 이유를 읽어 정리해보자고 한다.

명령 모델

명령 모델의 단위 테스트

명령 모델이란? -> CQRS 참고..

1.단위 테스트에서 리포지토리의 대역은 가짜 대역을 사용

• TDD를 연습하며 보았지만, 테스트를 위해 Repository단의 대역을 모의객체(ex:Mock)를 사용하면 테스의 복잡도가 계속 커진다고 한다. 그렇기 때문에 대역을 가짜 구현을 만들어 테스트 한다고 했다.
• 인터페이스에 메서드가 적어야 가짜 구현 만들기가 쉽다.

2.JpaRepository에 메서드가 너무 많음

• JPA 레포지토리를 상속한 인터페이스를 가짜 구현체 MemryRepository를 만들어 테스트 한다면..

  public MemoryRepository implemets UserRepository {
  		약 20여개의 메서드를 overide해 구현해야 한다.
  }

필요한 메서드만 사용하자

1. 명령 모델의 리포지토리는 필요한 메서드가 매우 적음

• findById 또는 findOne, save 정도가 필수.
• 이후 도메인이 제공할 기능에 따라 필요한 메서드 추가 필요(몇가지 필요 하지 않다)

2. JpaRepository를 상속하면 필요하지 않은 메서드를 오용할 가능성이 있다.

• 기본적으로 사용할 수 있는 메서드들이 많다보니

조회 모델

마찬가지로 JpaRepository 상속 x. save(), delete() 같은 메서드가 있다는게 이상함.따라서 Repository를 상속하고 필요한 메서드를 그때그때 추가

조회 모델 구현 (이는 어디까지나 선택)

• 다양한 스펙 조합이 필요하면 JPA,
• 단순 조회시 JdbcTemplate
• 쿼리가 복잡하면 MyBatis
  -> 개인적으로는 JPA를 사용하는 것을 선호

정리

JpaRepository를 상속하면 편하지만 단위 테스트에서 가짜 구현을 만들기 어렵고, CQRS에는 맞지 않다. 그래서 Repository를 상속하고 필요한 메서드만 추가.

'

이런식으로 Repository를 상속받아 구현하면, 원하는 기능들만 넣어줄 수 있다. CRUD 관련해서 실제로 사용할때도 쓰지 않는 기능들을 막을 수 있고, CQRS 구현에 있어서 JpaRepository를 상속받는 것 보다는 이런식으로 하는 것이 테스트, 필요하지 않는 메서드의 오용을 막을 수 있다.