- 인터페이스를 상속받은 클래스에 인터페이스의 구현체가 없으면 오류가 나는데 JPA 레포지토리를 상속받은 레포지토리 인터페이스는 구현체가 없어도 오류가 나지 않는 이유?
: JPA 레포지토리는 마킹 인터페이스이며, JPA는 이 인터페이스를 구현한 클래스를 자동 생성해 준다. 또한 spring은 레포지토리 인터페이스를 인식하고 그에 맞는 구현체를 런타임에 생성하기 때문에 명시적인 구현체를 생성하지 않아도 된다.
- 테이블 관계에 대해서 외래 키를 관리하는 테이블을 정하는 기준?
: 데이터의 양과 소유권에 따라 결정할 수 있다. 데이터가 더 많은 테이블은 @ManyToOne을 가지고, 더 적은 쪽의 주요 키를 외래 키로 가진다. 가령 유저는 주문보다 적고, 유저가 주문을 소유하는 쪽이기 때문에 유저 테이블의 주요 키는 주문 테이블에 외래 키로 위치한다.
- EntityManagerFactory는 springboot 프로젝트에서도 크게 신경을 쓸 필요가 있을까?
: springboot 프로젝트는 JPA와 Hibernate를 자동으로 설정해 주기 때문에 개발자의 직접적인 설정은 크게 필요가 없으며, 필요한 경우에만 EMF를 커스터마이징할 수 있다.
- SpringBoot의 적용으로 인해 개발자가 직접적으로 관리하지 않아도 되는 내부적인 Bean 관리 절차에는 어떤 것들이 있는지?
: 의존성 주입, 컴포넌트 스캐닝, 생명주기 관리 등이 있다. 이러한 자동화 로직으로 인해 비즈니스 로직과 Bean 관리를 위한 설정이 줄어든다.
- cascade = CascadeType.REMOVE 설정의 단점?
: REMOVE 속성으로 설정하게 되면 여러가지 단점이 따른다. 부모 엔티티가 삭제되면 자식 엔티티도 따라서 삭제되는 속성이기 때문에 예기치 않은 중요한 데이터가 삭제될 가능성도 생긴다. 또한 자식 엔티티가 다른 엔티티와 참조 관계를 갖고 있다면 이런 부분에서도 데이터 무결성이 지켜지지 않는다. 추가적으로는 트랜잭션의 복잡성, 성능 / 유지보수 면에서도 좋지 않기 때문에 이 속성보다는 서비스 로직에서 명시적으로 어떤 데이터를 삭제할지에 대한 삭제 로직을 구현하는 등의 방법이 더 안전하다.
- 1) 영속성 전이의 설정을 REMOVE로 설정하는 것
- 2) 고아 객체 제거 설정
두 설정의 차이는?
: 1) 부모 객체가 삭제된다는 전제 하에 자식 객체도 따라서 삭제됨.
2) 부모 객체의 삭제와는 관련이 없으며 자식 객체가 부모 엔티티의 컬렉션에서 삭제되면 자식 객체가 사라짐.
