가급적 getter 만 열어두고 setter는 사용하지 않는다.
변경시에는 setter가 아닌 변경 지점이 명확하도록 변경을 위한 비즈니스 로직을 별도로 제공할 것
OneToOne 관계 같은 경우 FK를 어디에 두어도 상관이 없다. ACCESS 를 자주 하는 곳에 두는 게 좋다.
FK를 가지고 있는 쪽에서 값을 넣어야 반대편이 변경될 수 있다. 연관 관계의 주인에서 값을 넣으면 변경되지 않는다.
@Enumerated(EnumType.String) Ordinary 로 타입을 줄 수 있으나 나중에 상태가 추가되었을 경우 크게 문제가 생길 수 있다. String 타입으로 넘겨주는 게 현명하다.
상속 하는 클래스 엔티티 들의 경우
실무에서는 다대다 관계를 거의 쓰지 않는다.
엔티티 클래스를 생성해서 자동으로 생성되는 DDL 을 데이터 베이스에 그대로 사용하면 될까??
엔티티 설계시 주의점
컬렉션은 필드에서 바로 초기화 하는 것이 베스트 방법이다.
@OneToMany(mappedBy = "order", cascade =ALL)
private List<OrderItem> orderItems = new ArrayList<>();
테이블 컬럼명 생성 전략
대문자는 인식하지 않기 때문에 사용하지 않는다.
엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 활용하는 것을 도메인 모델 패턴이라 한다.
반대로 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 트랜잭션 스크립트 패턴이라고 한다.