부록: JPA 엔티티에 UserDetails, OAuth2User 구현하지 말기

이전에 UserDetails와 OAuth2User를 바로 엔티티에 구현했던 적이 있었다.

JPA는 하이버네이트 프록시 클래스 인스턴스를 생성해 반환하는 것을 알고난 후 그만두게 되었다.

영속성 범위에 따라 fetch 문제가 생길 수 있다.

물론 다음과같은 방법으로 실제 인스턴스를 반환받아 사용할 수도 있다.

Hibernate.unproxy(paymentReceipt.getPayment());

참고:
https://www.baeldung.com/hibernate-proxy-to-real-entity-object

 

하지만 코드에 직관성이 떨어지며 해당 Principal로 반환된 인스턴스가 하이버네이트 프록시인지 아닌지 다른 로직에서 검사해야하는 골치아픔이 남게된다. 필드가 프록시인지 아닌지 항상 의심해야하는 상황이 발생하는 것이다.

 

또한 Principal로 들어갈 가능성이 있는 클래스기 때문에 프레젠테이션 레이어로의 침범 가능성도 있으며

JPA 엔티티가 스프링 시큐리티에 의존성이 생기게 된다.

 

해당 부분은 개인적인 아키텍쳐 취향이지만 이 또한 해당 의사결정의 이유다.

따라서 예제에선 최대한 별도의 클래스에 해당 인터페이스를 구현할 것이다.