Entity
- @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.
- JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
- 주의
- 기본 생성자 필수( public 또는 protected 생성자 )
- final 클래스, enum, interface, inner 클래스 사용X
- 저장할 필드에 final 사용 X
필드와 컬럼 매핑
새로 배운 어노테이션 columnDefinition, precision, scale(DDL)
- 그리고
@Lob: 데이터베이스 BLOB, CLOB 타입과 매핑- @Lob에는 지정할 수 있는 속성이 없다.
- 매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
- CLOB: String, char[], java.sql.CLOB
- BLOB: byte[], java.sql. BLOB
복기해야하는 @Transient
@Transient
private Integer temp; - 필드 매핑X
- 데이터베이스에 저장X, 조회X
- 주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용
기본 키 매핑
IDENTITY 전략 - 특징 (중요)
-
기본 키 생성을 데이터베이스에 위임
-
주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용
(예: MySQL의 AUTO_ INCREMENT) -
JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
-
AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
-
IDENTITY 전략만 예외적으로 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
System.out.println("==================");
em.persist(member);
System.out.println("==================");
System.out.println(member.getId()); // 1
// 보통이라면 commit전이기 때문에 출력되지 않지만,
// IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고
// DB에서 식별자를 조회하기 때문에 1이 출력된다.
실전 예제1 - 요구사항 분석과 기본 매핑
데이터 중심 설계의 문제점
- 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
- 테이블의 외래키를 객체에 그대로 가져옴
- 객체 그래프 탐색이 불가능
- 참조가 없으므로 UML도 잘못됨
Order order = em.find(Order.class, 1L);
Long memberId = order.getMemberId();
Member member = em.find(Member.class, memberId);위의 코드(관계형 DB 맞춤설계)는 객체지향적이지 않다.
객체지향적인 코딩을 위해 도메인의 필드가 Long 타입의 Id값이 아닌 객체로 넣는것이다.
객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.
• 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
• 객체는 참조를 사용해서 연관된 객체를 찾는다.
• 테이블과 객체 사이에는 이런 큰 간격이 있다
단방향 연관관계
@Entity
public class Member {
@Id @GeneratedValue
private Long id;
@Column(name = "USERNAME")
private String name;
// @Column(name = "TEAM_ID")
// private Long teamId;
@ManyToOne
@JoinColumn(name = "TEAM_ID") // (객체의 참조와 테이블의 외래 키를 매핑)
private Team team;
양방향 연관관계와 연관관계의 주인1 - 기본
양방향의 개념을 공부하기가 많이 어렵다. 그 이유는 객체와 테이블의 패러다임의 차이때문이다. 객체는 참조라는 걸 사용하고, 테이블은 외래키를 가지고 조인을 한다.
이 둘 간의 차이가 뭔지, 차이에서 오는게 뭔지를 이해해야 한다. 그래야 연관관계 주인이라는 개념을 알 수 있다.
객체의 양방향 관계
- 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2개다.
- 회원 -> 팀 연관관계 1개(단방향)
- 팀 -> 회원 연관관계 1개(단방향)
- 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.
- A -> B (a.getB())
- B -> A (b.getA())
테이블의 양방향 연관관계
-
테이블은 외래 키 하나로 두 테이블의 연관관계를 관리
- 회원 <-> 팀의 연관관계 1개
-
MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐
(양쪽으로 조인할 수 있다.)
SELECT *
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_IDSELECT *
FROM TEAM T
JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID
연관관계의 주인(Owner)
- 양방향 매핑 규칙
- 객체의 두 관계중 하나를 연관관계의 주인으로 지정
- 다시 말해서, 외래키가 있는 곳을 주인으로 지정
- 연관관계의 주인만이 외래 키를 관리(등록, 수정)
- 주인이 아닌쪽은 읽기만 가능
- 주인은 mappedBy 속성 사용X
- 주인이 아니면 mappedBy 속성으로 주인 지정
양방향 연관관계와 연관관계의 주인2 - 주의점, 정리
양방향 연관관계 주의 - 실습
- 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자
- 양쪽으로 값을 세팅해주는게 객체지향적이고,
- 두번째로, 마찬가지로 테스트 코드 작성시 순수 객체를 사용해서 테스트 하기 때문에
- 연관관계 편의 메소드를 생성하자
- 사람이 코딩을 하기 때문에 깜빡하고 잊을 수도 있다. 그것을 방지하는게 목적.
- 둘다 해서는 안되고, 둘 중 편한 방식으로 하나만 하면 된다.
// Member쪽에 했을 경우 public void setTeam(Team team) { this.team = team; team.getMembers().add(this); } // Team쪽에 했을 경우 public void addMember(Member memeber) { member.setTeam(this); members.add(member); } - 양방향 매핑시에 무한 루프를 조심하자
- 예: toString(), lombok, JSON 생성 라이브러리
- 엔티티는 바로 반환하지말아라. 그때 바로 무한루프에 걸린다. Dto변환해서 응답할것.
양방향 매핑 정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료
- 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
- 객체는 가급적이면 단방향 매핑이 좋다. 양방향으로하면 신경이 써야하는게 점점 많아진다.
- JPQL에서 역방향으로 탐색할 일이 많음.
- 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨 (테이블에 영향을 주지 않음)
