분류 전체보기
-
[Spring] 테이블, 컬럼명 생성 전략Spring 2021. 11. 9. 21:39
스프링 부트에서 하이버네이트 기본 매핑 전략을 변경해서 실제 테이블 필드명은 다르다. 하이버네이트 기존 구현은 엔티티의 필드명을 그대로 테이블의 컬럼명으로 사용한다.(SpringPhysicalNamingStrategy) 스프링 부트 신규 설정에 의해 그 규칙이 바뀌었는데, 엔티티(필드) -> 테이블(컬럼) 1. 카멜 케이스 -> 언더스코어 (memberPoint -> member_point) 2. .(점) -> _(언더스코어) 3. 대문자 -> 소문자 이렇게 기본세팅은 이렇지만, 회사나 단체의 규정에 따라 커스텀이 필요할 때가 있다. 1. 논리명 생성 : 명시적으로 컬럼, 테이블명으로 직접 적지 않으면 ImplicitNamingStrategy 사용 spring.jpa.hibernate.naming.imp..
-
[Spring] 컬렉션은 필드에서 초기화해야 하는 이유Spring 2021. 11. 9. 21:32
컬렉션은 필드에서 바로 초기화 하는 것이 안전하다. - null문제에서 안전하다. - 하이버네이트는 엔티티를 영속화 할때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 getOrders()처럼 임의의 메서드에서 컬렉션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다. 따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다. 출처 :실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 학습 페이지 (inflearn.com)
-
[Spring] 모든 연관관계는 지연로딩으로 설정해야하는 이유Spring 2021. 11. 9. 21:24
- 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. - 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다. - 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다. - @XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다. 출처 : 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 학습 페이지 (inflearn.com)
-
[Spring] @ManyToMany를 사용 안 하는게 좋은 이유Spring 2021. 11. 9. 19:24
@ManyToMany는 편리한 것 같지만, 중간 테이블에 컬럼을 추가할 수 없고, 세밀하게 쿼리를 실행하기 어렵기 때문에 실무에서 사용하기에는 한계가 있다. 중간 엔티티를 만들고 @ManyToOne, @OneToMany로 매핑해서 사용하자. 정리하면 대다대 매핑을 일대다, 다대일 매핑으로 풀어내서 사용하자 출처 : 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 학습 페이지 (inflearn.com)
-
[Spring] 값 타입 Entity 클래스를 불변하게 설계하는 방법Spring 2021. 11. 9. 19:09
값 타입은 immutable(불변)하게 설계되어야 한다. 때문에 Setter를 열어두지 않고, 생성자로만 값을 변경하도록 만들어야한다. JPA 스펙상 엔티티나 임베디드 타입(@Embeddable)은 자바 기본생성자(default constructor)를 public 또는 protected로 설정해야 한다. public으로 두는 것 보다는 protected로 설정하는 것이 그나마 안전하다. JPA가 이런 제약을 두는 이유는 JPA 구현 라이브러리가 객체를 생성할 때 리플렉션 같은 기술을 사용할 수 있도록 지원해야하기 때문이다. 출처 : 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 학습 페이지 (inflearn.com)
-
[Spring] 실무에서 가급적 Entity 클래스에 Setter 사용을 자제해야 하는 이유Spring 2021. 11. 9. 19:02
이론적으로 Getter, Setter 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적이다. 하지만 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로, Getter의 경우 모두 열어두는 것이 편리하다. Getter는 아무리 호출해도 호출 하는 것 만으로 어떤 일이 발생하지는 않는다. 하지만 Setter는 문제가 다르다. Setter를 호출하면 데이터가 변한다. Setter를 막 열어두면 가까운 미래에 엔티티가 도대체 왜 변경되는지 추적하기 점점 힘들어진다. 그래서 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다. 출처 : 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 학습 페이지 (i..
-
[Spring] Entity 설계 시 연관관계의 주인을 설정하는 법Spring 2021. 11. 9. 18:39
연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다. 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다(많은) 쪽에 외래 키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능 한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. 연관관계의 주인이 아닌 곳은 읽기만 가능하며, 주인은 mappedBy 속성사용을 하지 않으며, 주인이 아니면 mappedBy 속성으로 주인을 지정한다. 단방향 매핑만으로도 이미 연관관계..