[JPA] JPA를 사용하는 이유 및 객체와 SQL 중심의 개발 문제점

김영한님 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라는 기술이 나왔다고 한다.