티스토리 뷰
김영한님 JPA 기본강의를 듣던 중 기본개념을 잡기 위해 작성한 글이다.
객체와 관계형 데이터 베이스의 쿼리 차이
연관관계
객체: Member를 통해 Team을 조회할 수 있으나 Team을 통해 Member를 조회할 수 없다.
- 참조를 사용: member.getTeam()
테이블 관계: Member가 Team을 그리고 Team이 Member를 조회할 수 있다.
-외래키를 사용 JOIN ON M.TEAM_ID = T.TEAM_ID
객체를 테이블에 맞추어 모델링 모습
class Member {
String id; // 회원 고유 id
long teamId; //조인하는 teamID
String username; //회원 이름
}
class Team {
Lond id; //팀 고유 idx
String name; // 팀이름
}
테이블에 맞춘 객체 저장 한다면..
class Member {
String id; // 회원 고유 id
long teamId; //조인하는 teamID
String username; //회원 이름
}
⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇
[SQL]
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ... // sql문법을 통해 객체가 저장된다.
sql에 집중해서 보자
객체지향적으로 모델링 개선으로 가능하지 않을까?
class Member {
String id; // 회원 고유 id
Team team; //team객체
String username; //회원 이름
Team getTeam() {
return Team
}
}
class Team {
Lond id;
String name;
}
⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇
[SQL]
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ... // sql문법을 통해 객체가 저장된다.
long teamId를 이용하는 것은 객체 지향적이지 않아 Team 객체를 선언하여 이용 하고자 했다.
member.getTeam.getId() 를 통해 Team의 id 값을 받아 올 수 있다.
그러나 Team 객체를 선언하고 객체 지향적으로 설계하여 사용하려고 보니 문제가 발생했다.
객체지향으로 만들었으나 조회에서 발생한 문제점
객체 모델링 조회
SELECT M.*, T.* FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
public Member find(String memberId) {
//SQL 실행 ...
Member member = new Member();
//데이터베이스에서 조회한 회원 관련 정보를 모두 입력
Team team = new Team();
//데이터베이스에서 조회한 팀 관련 정보를 모두 입력
//회원과 팀 관계 설정
member.setTeam(team); //**
return member;
SQL 짤 때 MEMBER와 TEAM을 조인하여 조회해야한다.
개발자가 직접 member와 team의 연관관계 설정 *member.setTeam(team)을 해주고
member를 리턴 해주어 값을 넣어주면 된다.
sql이 복잡하다 생산성이 떨어진다.엔티티 신뢰성 문제가 발생한다.
레이어드 아키텍쳐와 신뢰성
class MemberService {
...
public void process() {
Member member = memberDAO.find(memberId);
member.getTeam(); //???
member.getOrder().getDelivery(); // ???
}
}
조건: memberDao를 다른 A개발자가 만들었다고 가정하자.
memberDao.find에 파라미터로 memberId를 넘겨주어 member 객체를 찾는다고 이해할 것이고,
member객체의 .getTeam()을 통해 Team객체를 가져오고,
.getOrder를 통해 member객체의 주문 내역과,
.getDelivery를 통해 주문 상태를 가져올 수 있을 것이라고 생각할 것이다.
하지만.
주황 글씨가 쳐져 있는 부분 부터 확신할 수가 없다.
왜냐하면
DAO에서 어떤 쿼리가 날라 갔는지 직접 보지 않는 이상 알 수 없기 때문이다
즉 레이어드 아키텍쳐간 신뢰성이 없으므로
반환된 엔티티(Member)를 사용할 수 없다.
물리적으론 Service, Entity, Dao등 나눠져 있지만 논리적으론 개발자가 직접 봐야한다
결론
객체는 나쁘지 않지만..
Member와 Team 엔티티를
객체를 자바 컬렉션으로 넣고 꺼내고 하기엔 좋지만
list.add(member) // member추가
Member meber = list.get(memberId); //아이디로 member 조회
Team team = member.getTeam(); // 해당 member의 team 조회
SQL을 이용하여 객체가 아닌 데이터베이스 테이블을 조회하고 추가하는데는 다른 개념!!
자바진영의 고민
+ 객체답게 모델링이 늘어날수록 매핑 작업이 늘어남.
+ 객체를 자바컬렉션에 저장하듯 DB에 저장할 순 없을까?
.
.
.
그래서 JPA가 나왔다
객체답게 모델링이 늘어날수록 매핑이 늘어나고,
객체를 자바컬렉션에 저장하듯 사용할 수 있는 방법으로
JPA라는 기술이 나왔다고 한다.
'💻 개발 > JPA, Querydsl' 카테고리의 다른 글
[JPA] 양방향 연관관계 주인 @ManyToOne / @OneToMany / MappedBy 선언위치 (0) | 2022.07.11 |
---|---|
[JPA] @Entity란? / @Entity주의사항 / 리플랙션 (0) | 2022.07.10 |
[JPA] 영속성 컨텍스트 | JPA 내부에서 어떻게 동작하는가? (0) | 2022.07.09 |
[Querydsl][오류] Cannot delete or update a parent row: a foreign key constraint fails (0) | 2022.07.08 |
[설정] 인텔리제이 queryDsl 인식하지 못하는 오류 (0) | 2022.06.16 |
- Total
- Today
- Yesterday