Ch01. JPA 소개 - SQL 중심적인 개발의 문제점

현재 거의 모든 개발은 객체지향 개발을 하고, 관계형 DB를 사용한다.

SQL위주의 코드 작성이 너무 많다.

• CRUD 코드를 작성하기 위해 SQL을 계속 작성해야 한다.
• 객체지향 코드가 아닌 SQL을 작성하기 위해 너무 많은 시간을 소비하는 문제가 있다.
• SQL에 의존적인 개발에 피하기 어렵다.

패러다임의 불일치 문제 발생

객체를 RDB에 저장하기 위한 경로

 

• 개발자가 SQL 변환 역할을 다 해주니 모든 SQL을 다 작성해야 한다(개발자 == SQL 매퍼)

객체지향 상속

 

객체 지향의 상속 VS 관계형 DB에서의 슈퍼타입 서브타입 관계

• 객체지향에서 상속이라는 개념을 RDB에서는 Table에 슈퍼 타입-서브타입 관계로 풀어낼 수 있다.
• 단, 이과정에서 테이블에 데이터를 넣고 빼고 하는 과정에서의 SQL은 모두 개발자가 작성해야 됐는데, 상속받는 테이블이 많을수록 SQL을 일일이 작성하고, 수정하는 일이 너무 많다.
• 하지만 객체지향에서의 컬랙션을 이용한다면?
  • list.add(album);
  • 한 줄이면 된다.
  • 부모 타입으로 조회 후 다형성 활용도 가능하다.

객체지향 연관관계

• 객체는 참조, 테이블은 외래 키를 사용한다.

객체의 참조 VS 테이블의 외래키

• 객체는 한방향으로 Member에서 Team을 참조할 수 있지만 Team으로 멤버를 참조할 수 없다(단, 테이블은 양방향 참조가 가능하다)

• 연관된 두개의 테이블을 조회해 오기 위해서는 위와 같이 복잡한 과정이 필요하다.(생산성이 안 나온다)

• 

  객체지향이였다면 해당 코드면 해결된다.

객체 그래프 탐색

• 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.

SQL 의존적인 개발의 단점, 조회하는 범위에 따라 SQL을 새로 작성해야 하는 단점이 있다(엔티티 신뢰 문제)

• 처음 실행하는 SQL을 확인하기 전까지는 엔티티의 탐색이 어디까지 이루어져 있는지 알 수가 없다.
  • member.getOrder()라는 함수가 있어 호출을 하였지만 SQL에서 값이 채워져 있지 않기 때문에 엔티티를 신뢰하고 사용할 수가 없다.

비교하기 

• 트랜잭션 안에서 객체는 주소 값을 비교하고, 테이블은 PK를 비교한다.
• member1 == member2 (해당 두 값은 자바에서 다르다)
• JPA에서는 두 값이 항상 같음을 보장한다

객체답게 모델링할수록 매핑 작업만 늘어난다.

이를 해결하기 위해 JPA가 나왔다