Repository 인터페이스를 설계할 때 메소드 이름을 spring data jpa를 고려해서 해야 하나요?

Question

스프링 데이터 JPA를 대비해서 메소드 이름을 그에 맞게 정해두셨다고 하셨는데요. 실무에서 스프링 데이터 JPA 말고 다른 기술을 결정했을 때도 메소드 이름을 그렇게 설계하는지 궁금합니다. 예를 들어서 mybatis를 사용해서 프로젝트를 진행한다고 결정했을 때 먼저 Repository 인터페이스를 설계 할텐데 인터페이스 메소드 이름을 스프링 데이터 JPA 형식에 맞지 않게 정했다면 나중에 스프링 데이터 JPA로 변경하기 곤란할 것 같습니다. 실무에서 스프링 데이터 JPA 말고 다른 기술을 사용하기로 결정했을 때도 이후에 스프링 데이터 JPA로 변경될 가능성을 고려해서 스프링 데이터 JPA의 Repository 메소드 이름 형식을 사용하나요? 만약 스프링 데이터 JPA 메소드 이름 형식을 사용하지 않는다면 어떻게 해결하는지도 궁금합니다.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴이에요. 스프링 데이터 JPA에서는 메소드 이름을 통해 쿼리를 생성할 수 있기 때문에 해당 기술을 사용할 때는 메소드 이름을 스프링 데이터 JPA 형식에 맞게 설계하는 것이 일반적입니다. 하지만 실무에서는 스프링 데이터 JPA가 아닌 다른 기술을 사용할 수도 있습니다. 이 경우에는 스프링 데이터 JPA의 Repository 메소드 이름 형식을 사용하지 않게 됩니다. 만약 이후에 스프링 데이터 JPA로 변경될 가능성을 염두에 두고 설계를 진행해야 한다면, 다음과 같은 방법을 고려할 수 있습니다. 공통 인터페이스를 설계합니다. 스프링 데이터 JPA의 Repository 인터페이스를 직접 상속 받는 대신, 프로젝트에서 공통으로 사용되는 메소드를 정의한 인터페이스를 따로 설계합니다. 이렇게 설계된 인터페이스는 JPA 이외의 다른 기술에서도 사용할 수 있게 됩니다. 구현 클래스에서는 해당 인터페이스를 구현하고, 필요한 메소드를 직접 구현합니다. 스프링 데이터 JPA와 같은 기술이 아닌 경우에는 메소드 이름에 따라 쿼리를 자동으로 생성할 수 없기 때문에, 직접 쿼리를 작성해서 해당 인터페이스의 메소드를 구현해야 합니다. 물론, 스프링 데이터 JPA와 다른 기술 간의 전환에는 코드의 일부 수정이 필요하게 됩니다. 하지만 공통 인터페이스를 운영하고, 필요한 메소드를 구현 클래스에서 직접 구현하는 방식을 사용한다면 전환 작업에 대한 유연성을 확보할 수 있습니다. 이러한 방법을 통해 스프링 데이터 JPA가 아닌 다른 기술을 사용하더라도 나중에 스프링 데이터 JPA로 변경될 가능성에 대비할 수 있습니다. 질문이 있다면 언제든지 물어보세요!