JPA에서 왜 기본 생성자는 왜 public 또는 protected여야 할까?

 

Introduction

 

 

 

JPA 강의를 듣다가, JPA 엔티티는 꼭 기본 생성자를 생성해야 한다라고 들었는데, 강의 상의 간략한 내용으로는 jpa프록싱 할때 필요하여 기본 생성자가 있어야한다 ! 라고만 설명을 들어서 , 왜 기본 생성자를 반드시 갖추어야 하는지 궁금해서 더 찾아 봤습니다.

 

 

 

JPA ORM 

 

 

먼저 JPA 생성자 전에, JPA ORM 에 대해서 간략히 설명하겠습니다. 

JPA(Java Persistence API)는 Java에서 제공하는 ORM(Object-Relational Mapping) 프레임워크로, 객체와 관계형 데이터베이스 사이의 매핑을 쉽게 처리해줍니다. 그러나 이 JPA를 사용하려면 몇 가지 규칙이 있으며, 그 중 하나가 바로 '엔티티는 반드시 public 또는 protected인 기본 생성자를 가져야 한다'는 것입니다. 

 

 

 

Java Reflection API와 기본 생성자

 

 

그렇다면 왜 이런 원칙이 생겨난 것일까요? 이를 이해하려면 스프링에서 HTTP 요청을 받을 때 @RequestBody의 데이터를 DTO 객체로 바인딩하는 상황을 생각해보면 도움이 됩니다. 스프링이 @RequestBody의 데이터를 바인딩하려면 기본 생성자를 통해 객체를 만든 다음, Java Reflection을 통해 필드 값들을 채워넣습니다.

Java Reflection은 클래스의 이름만으로 그 클래스의 모든 정보에 접근할 수 있는 기술입니다. 하지만 생성자의 매개변수 정보까지는 Reflection이 다루지 못합니다. 그래서 Reflection을 통해 객체를 생성할 때 기본 생성자가 필요한 것입니다.

JPA 역시 이와 같은 방식을 따릅니다. 데이터베이스에서 데이터를 가져와 엔티티 객체를 만들 때도 Reflection을 사용하니, 기본 생성자가 없으면 안되는 것 이라고 합니다. 

 

 

 

 

기본 생성자가 private로 선언할 수 없는 이유

 

 

 

'기본 생성자를 private로 선언해도 되는지?'라는 질문이 생겨나실 수도 있습니다. Reflection이 객체를 생성할 때 기본 생성자의 접근 제어자가 private여도 문제 없지 않을까하는 생각이 들겠지만, 이는 JPA에서 Proxy와 Lazy Loading을 고려하지 않았을 때의 이야기입니다.

Lazy Loading은 연관된 엔티티 정보를 즉시 가져오는 Eager Loading과 대비되는 개념으로, 데이터가 실제로 필요한 시점에만 조회해오는 방식입니다. 

 

JPA가 엔티티를 지연 로딩으로 조회할 경우, Hibernate는 프록시(Proxy) 객체를 생성하여 사용합니다. 

이 프록시 객체는 실제 엔티티 클래스를 상속받은 객체로, 그렇기 때문에 기본 생성자가 반드시 public 또는 protected로 선언되어야 합니다!

만약 기본 생성자가 private으로 선언되어 있다면, 이를 상속받은 프록시 객체의 생성이 불가능해집니다. 

왜냐하면 상속한 객체의 생성자는 반드시 부모 객체의 생성자를 호출해야 하지만, private은 상속받은 클래스에서 호출할 수 없기 때문입니다.

 

이를 위해 필요한 프록시 객체는 실제 엔티티 클래스를 상속받아 만들어지는데, 만약 기본 생성자가 private라면 상속받은 프록시 클래스에서 호출할 수 없어서 문제가 발생하게 됩니다.

 

 

Conclusion

 

 

따라서, JPA에서 엔티티의 기본 생성자는 반드시 존재해야 하며, 이는 Reflection API를 통해 객체를 생성하기 위함입니다. 또한, 이 기본 생성자의 접근 제어자는 public 또는 protected여야 하는데, 이는 프록시 객체를 위한 것입니다. 이런 규칙을 준수함으로써 JPA는 객체와 데이터베이스 사이의 매핑을 원활하게 수행할 수 있습니다!

 

보다보니 다음에는 Reflection Api 에 구조에 대해서 조금 더 호기심이 생겨서, 적어 보도록 하겠습니다.