실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션2. 도메인 분석 설계

쇼핑몰 만든건데 요구사항

 

이해한 내용이 너무 없는데, 이론편을 배우고 실전편을 배우는 걸로 진행을 해야 해서 그런 것 같다.

 

일단 이런게 필요하겠구나 하고 대략적으로 구성한 다음에 속성은 뭐가 필요할지, 그 속성이라면 테이블은 어떻게 할지 구체적으로 정하는 것 같다.

여기에서 강조한건 다대다는 운영에서 제약이 많기 때문에 안좋다. 또 양방향 관계도 양쪽이 서로를 참조하고 있어서 누가 주인인지 명시해야 해서 방침을 정하는 등 더 복잡해지고 이점은 단방향으로만 가능한 경우가 많아서 안하는게 좋다.

 

여기서 강조한건 외래키를 가지고 있는 애가 연관관계의 주인이라는 것. 다대일 에서 일쪽이 외래키를 가지고 있으려면 리스트 안에 등록하고 난리나니까 다쪽에 외래키로써 누가 주인인지 들고 있는게 db 구조다.

다대다 구조라 중간에 테이블 있는거. 또 오더도 여러개, 아이템도 한번에 여러개를 담고 갯수도 여러개 있을 수 있으니까 중간에 테이블을 사용하는 모습.

 

그럼 위 회원 엔티티 분석을 보고 막 만드는데 너무 많다..

 

db엔 상속 개념이 없기 때문에 구체적인 자식 클래스를 모두 포함하는 전체의 테이블이 만들어지고 이걸 사용한다는 것, 단방향과 one to many, many to one의 개념도 있고 방향을 가진다는건 그 객체를 가지고 있다는 것. mappedBy는 db는 방향 개념이 없어 어느쪽을 바꾸든 그냥 바뀌기 때문에 한쪽에서만 바꿔야 혼란을 피할 수 잇다. 그래서 양방향으로 참고할 때 어느애를 주인으로 봐서 누가 바뀔 때 실제 db를 바꾸는지 정한다.

 

이건 실습이라 몇 가지를 편의상 넘겼는데, 주의점은 @Setter를 이런식으로 막 정의하면 안된다는 것, 다대다는 실무에서 절대 쓰지 말것. 다대다로 하면 중간 테이블 때문에 뭔가를 더 추가하기가 불가능해진다고 함.

 

엔티티 설계시 주의점들이 있는데, 일단 엔티티에는 setter를 사용하지 말 것. 여기저기 쓰는걸 방지하기 위함임.

두번째는 모든 관계는 지연로딩으로 설정해야 한다. 즉시로딩은 EAGER고 지연로딩은 LAZY이다. 그래서 @XToOne은 왜인지 즉시 로딩이 default라서 얘내들을 찾아서 LAZY로 바꿔줘야 한다.

이렇게

바꾸지 않으면 기껏 불러왔는데 만약 다른 테이블이 왜래키로써 있다면 그 테이블 정보를 다 불러오기 위해 select 해서 불러진 갯수만큼 일일히 요청을 날리기 때문에 낭비가 엄청 심함. 이를 n + 1 이라고 함. 안그러면 앞으로 사용하지 않을지라도 혹시 모르니 자신의 자식 리스트를 위해 싹싹 긁어모아 성능 낭비가 심해짐.

 

또 List같은 컬렉션은 필드에서 초기화 해야 한다. 만약 해당 컬렉션에 엔터티가 추가되면 그 엔터티가 변할 때 자동으로 변하는걸 hibernate가 감지해서 db에 적용한다는걸 알고있다. 따라가는 프록시 클래스가 한번이라도 변경되면 그걸 hibernate에서 추적할 수 있도록 내부 매커니즘 컬렉션으로 바뀌는데 이 프록시 클래스를 다른걸로 정의하여 덮어씌우면  프록시 클래스가 사라지면서 추적이 안되 적용이 제대로 안된다. 그래서 필드에서 한번 초기화 한 뒤 그 컬렉션 변수를 다른걸로 다시 덮어씌우면 안된다.

 

남은건 뭐 테이블 명 조심하고.. db는 대소문자 구분 안하니 클래스의 이름을 따서 테이블 명을 camel case를 snake case로 자동으로 바꿔서 하는 전략 단계가 있다. 이런게 지정하지 않아 알아서 해주는 논리명 적용이고 각 회사 사정에 따라 직접 물리명을 적용할 수도 있다.