주의점 메모장
update와 같은것들은 왠만해서는 한가지 일만 해라
여기서 void가 아니라 Member를 반환하면 Update도 하고 Member도 반환하는 꼴이 되기 때문이다. 할 수있다면 분리하자
분류 전체보기
주의점 메모장
API 개발 시 Entity를 직접 끌어와서 값을 받지 말아라
DTO를 만들어 따로 받아서 만들어라 그렇게 안하면 Entity스팩이 바뀌어버리면 유지보수가 힘들어지며 머리가 아파져버린다. 만약 password를 api로는 password를 받는다고 하는데 갑자기 Entity의 스팩에서 password가 없어져 버리면 그때는 머리가 아파진다. 이런식으로 DTO로 받아내면 좋다. Entity가 바뀐다고 DTO가 바뀌는것이 아니기 때문이다.
메모장
맵핑 테이블을 만들 때 생각해야 하는점
각각의 테이블은 동격이라고 봐야한다 회원이 주문을 할 때를 예시로 들면 회원테이블은 주문을 할 때 주문 테이블을 필요로 한다. 주문 테이블은 주문을 할 때 회원테이블을 필요로 한다. 추가적으로 1 : N을 쓰려고 생각할 때 이렇게 생각해 보자 "좋아 1 : N이면은 개발자가 조금은 객체를 관리하기에는 편하겠지 그런데 그건 개발자 입장이고 테이블 입장에서는 어떻지?" 1 : N고 같이 양방향을 할 때 어떠한 조건이 충족하는지 생각을 한 후 만들어야 하는가?(모름 물어보자)
주의점 메모장
Embeddable 만들 때 주의점
Embeddable과 같은 값타입은 기본 생성자를 public 또는 protected로 설정해야 한다 함 그리고 setter또한 막아두자 값타입은 불변이여야 함 JPA가 이런 제약을 두는 이유는 JPA구현 라이브러리가 객체를 생성할 때 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문임 그리고 누가 마음대로 생성하지 못하게 하기 위해서
메모장
컬렉션은 필드에서 초기화 하자
null문제에서 안전해지며 하이버네이트가 엔티티를 영속화 할 때 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경하여 getOrders 처럼 임의의 메서드에서 컬렉션을 잘못 생성하면 하이버 네이트에서 내부 메커니즘에 문제가 발수 이쓴데 이를 방지해주며 코드도 간결해진다. 그리고 변경하지 말아라 그냥 있는거 그대로 써라 안그러면 하이버네이트가 원하는 동작대로 동작을 하지 못할 수 있기 때문이다.
메모장
연관관계 편의 메서드
setter말고 다른거 쓰자 builder라던가 생성자라던가 factory메서드를 쓰자 팩토리 @Entity public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @OneToMany(mappedBy = "user", cascade = CascadeType.ALL, orphanRemoval = true) private final List orders = new ArrayList(); // 생성자를 통해 User 객체를 생성합니다. public User() { // 초기화 로직 } // Order 객체를 추가하는 편의 메서드 public void addOrder(Order order) { orde..
