-
@JoinColumn
@ManyToOne을 할 때 어떤 Entity를 연결하는지 알려주는 어노테이션
@JoinColumn옆에 name에 연결하는 Entity에서 어떤 값으로 비교하여 받아오고 싶은지에 대한 값
private Member member; 연결하는 Entity -
@OneToMany
ERD 작성시 Entity간 연결되는 선 끝 부분 모양을 확인하여 작성하는 부분
-
fetch = FetchType.LAZY (fetch : 잡아오다.) 지연로딩
쿼리시 한 번에 가져온다. -
LAZY 대신 EAGER 입력 바로 바로 가져오기 때문에 한꺼번에 가져오지 않는다.
(쿼리가 여러번 나간다.) -
mappedBy = "member"
연간관계의 주인을 말한다.(OneToMany의 One부분) ex) 부모 자식간의 부모부분 -
cascade = CascadeType.ALL
부모를 지울 때 자식을 같이 지워준다. -
orphanRemoval = true
부모를 지울 때 자식이 남아 있을 경우 확인하여 지워준다. -
private Set commentSet = new HashSet<>(); -> 기본자바문법
Set은 수학에서 교집합, 합집합 같은 집합에서 교집합을 의미한다.
-> Set을 할 경우 데이터를 순서대로 가져오지 않고 교집합만 하기 때문에 데이터순서가 섞여 처리하는데 어려움이 생길 수 있다.(쓰는 이유는 교집합을 의미하기 때문에 중복된 값을 받아오지 않기 때문에 중복에러를 방지 할 수 있다.)
private List commentList = new ArrayList<>();을 적어도 된다.
-> 위에 LAZY가 있기 때문에
- @ManyToOne
OneToMany에서 대부분 적었기 때문에 ManyToOne에는 지연로딩만 적어준다.
fetch = LAZY
지연로딩
-
@Builder
디자인패턴 중 하나로, 생성과 표현의 분리이다.
쉽게 말해 생성자에서 인자가 많을 때 고려해볼 수 있는 것이 빌더패턴이다.- 점증적 생성자 패턴
클래스를 설계하다 보면, 필수로 받아야할 인자들이 있고 선택적으로 받아야할 인자들이 있다.
이 때 필수적으로 값이 있어야할 멤버변수를 위해 생성자에 매개변수를 넣는다.
또한 선잭적 인자를 받기 위해 추가적인 생성자를 만든다. 이러한 상황을 Effectivce Java 2/E에서 점층적 생성자 패턴이라고 한다.
이런 설계에서의 단점이 있는데
- 인자들이 많아질수록 생성자가 많아진다.
- 매개변수의 정보를 설명할 수 없으므로 어떤 객체에 어떤 인자가 들어갔는지 알기어렵다.
이러한 단점을 보완하기 위해 "자바 빈즈 패턴"이 나오게 되었다.
-
자바 빈즈 패턴
자바 빈즈패턴을 사용하면 생성자의 단점으로 꼽혔던 가독성이 어느 정도 해결된다.
다만, 코드량이 늘어나는 단점이 존재하고 가장 문제가 되는점은 객체일관성이 깨진다는 것이다.객체일관성이 깨진다는 것은 한 번 객체를 생성할 때 그 객체가 변할 여지가 있다는 것이다.
코드를 보면 객체를 생성하고 그 뒤에 값을 떡칠한다.
-
빌더 패턴
둘의 단점을 모두 보완해서 나타낸 것이 바로 빌더패턴이다.
정보들을 자바빈즈패턴처럼 받되, 데이터 일관성을 위해 정보들을 다 받은 후에 객체를 생성한다.빌더패터의 장점
-
불필요한 생성자의 제거
-
데이터의 순서에 상관없이 객체생성 가능
-
명시적 선언으로 이해하기 쉬움
-
각 인자가 어떤 의미인지 알기 쉬움
-
setter메서드가 없으므로 변경 불가능한 객체를 만들 수 있다.
-
한 번에 객체를 생성하므로 객체일관성이 깨지지 않는다.
-
build()함수가 null인지 체크해주므로 검증이 가능하다.
(안 그러면 set하지 않은 객체에 대해 get을 하게 되는 경우 nullPointerExcetpin 발생 등의 문제)
- 점증적 생성자 패턴
