본문 바로가기

728x90

JAVA/JPA

(3)
JPA에서 Entity에 protected 생성자를 만드는 이유. 엔티티에서 setter를 쓰는 것보다 생성자를 통해 파라미터를 넘기는 게 좋다. Setter를 무분별하게 남용하다 보면 여기저기서 객체(엔티티)의 값을 변경할 수 있으므로 객체의 일관성을 보장할 수 없기 때문. 그리고 setter는 그 의도를 알기 힘들기에 setter 사용을 자제해야한다. 그러므로 protect 생성자를 생성해서 아무데나 생성되는 걸 막는 게 좋다. (다른 사람이 쓰지 못하도록 제약한다.) 예시) Address address = new Address(); address.setLocation("광안리"); address.setCity("서울"); 그러나 JPA 표준 스펙에 디폴트 생성자가 있어야하기에 private 생성자를 사용할 수 없다. 왜냐하면 jpa가 프록시 기술을 쓰는데 거기서 ..
JPA의 성능은 과연 괜찮을까? (칼럼 한 개 vs 객체 칼럼) JPA에서 select 성능 차이 보통 컬럼을 하나하나 찍는 것이 데이터 전송량이 줄어들기 때문에 성능상 더 유리합니다. 다만 이렇게 원하는 컬럼만 찍어서 조회하게 되면 재사용성이 떨어집니다. 예를 들어서 회원 엔티티가 있는데 name, age, tel 필드가 있습니다. A로직에서는 회원의 name, 데이터가 필요하고, B로직에서는 회원의 name, age 데이터가 필요하고, C로직에서는 회원의 name, age, tel이 모두 필요하다고 가정하겠습니다. 성능을 완벽하게 최적화하려면 select 쿼리를 3개 각각 만들어야 합니다. 대신에 회원 엔티티를 직접 조회하는(name, age, tel을 모두 조회하는) 쿼리는 하나만 있으면 됩니다. 결국 성능과 범용성의 트레이드 오프(양립할 수 없는)가 발생합니다..
JPA(1) - 도메인 설계 1. 관계 일대일, 일대다, 다대일 관계를 많이 사용한다. 그러나, 실무에서는 다대다 관계를 쓰면 안된다. => 다대다 관계면 중간 엔티티(매핑 테이블)를 만들고 일 대 다( 1:*), 다 대 일(*:1) 로 매핑하여 표현해야 한다. Why? 다대다는 실무에 한계가 있다. 예를 들어 회원이 상품을 주문하면 연결 테이블에 회원 아이디와 상품 아이디만 담고 끝나지 않는다. 보통 주문 수량 칼럼이나 주문한 날짜 같은 칼럼이 더 필요하다. 이런 칼럼을 추가하면 더는 다대다(ManyToMany)를 사용할 수 없다. 왜냐하면 주문 엔티티나 상품 엔티티에 추가한 컬럼들을 매핑할 수 없기 때문이다. 즉, 중간 테이블에 값을 넣을 수 없기에, 결국 다대다를 일대다, 다대일 관계로 풀어야 한다. 2. 연관관계 가급적 양방..

728x90