JPA 탄생배경

JPA 탄생배경

 1. SQL 중심적인 개발의 문제점

  - 반복되는 코드, 지루한 코드 ex)CRUD

  - 수정시 객체를 수정해야하며 동시에 DB 컬럼도 설정을 따로 해줘야한다.

따라서 SQL의존성을 많이 띄게된다.

 

2. 패러다임의 불일치

객체	관계형 DB
동일한 특성들을 묶어서 사용함을 목표로함	데이터를 정규화해서 보관을 목표로함

 서로 다른 목표를 가지고 있기때문에 설계에 어려움을 겪을 수 있다.

 

3. 객체와 관계형 데이터베이스의 차이

1. 상속 - 객체에는 상속관계가 존재하지만 관계형 DB에는 상속 관계가 없다(상속과 비슷한게 있지만 정확하게는 없음)

왼쪽이 객체 상속관계 오른쪽이 Table 슈퍼타입 서브타입 관계

ex)  - Album에 insert를 할 때 테이블이 2개이기 때문에 sql을 두번 작성해야한다.

       - Select시에는 join을 해야하며 movie를 가져올 때 또한 join을 걸어줘야한다.

      이것을 자바 컬렉션에서 조회하게 된다면 Album album = list.get(albymId);로 간편하게 조회할 수 있다.

 

2. 연관관계 - 객체는 get 등을 통하여 가져올 수 있고, DB는 join을 통해 가져올 수 있다.

 

4. 객체지향 모델링(자바컬렉션에 관리)

list.add(member);

Member member= list.get(memberId);

Team team = member.getTeam();

 - join없이 간편하게 상속된 객체를 가져올 수 있다.

 

5. 엔티티 신뢰 문제

class MemberService {

	public void process() {
    		Member member = memberDao.find(memberId);
    		member.getTeam();
    		member.getOrder().getDelivery();
  	}
}

find를 사용해서 member를 가져왔지만 실제로 find를 통해 사용된 sql문을 눈으로 직접 확인해보지 않는 이상 getTeam이나 getOrder는 어떤 쿼리문을 사용했는지 알 수 없기 때문에 신뢰할 수 없다.

 

따라서 SQL을 직접 다루게 된다면 진정한 의미의 계층 분할이 어렵다.

 

 

6. 비교하기

String memberId = 100;

Member member1 = memberDAO.getMember(memberId);

Member member2 = memberDAO.getMember(memberId);

 

member1 과 member2는 서로 다른 객체이다. 

 - 쿼리를 두번 날리고 값은 같지만 매번 새로운 객체를 반환하기 때문에 다른 것이다.

 

비교하기(자바 컬렉션에서 조회)

String memberId = 100;

Member member1 = memberDAO.getMember(memberId);

Member member2 = memberDAO.getMember(memberId);

 

member1 == member2 같다

 

 객체답게 sql에 모델링 및 테이블을 설계 할수록 매핑 작업만 늘어난다.

따라서 객체를 자바 컬렉션에서 저장 하듯이 DB에 저장하는 방법을 고민한 결과 JPA가 탄생하게 된 것이다.