JPA 소개

SQL을 직접 다룰때 발생하는 문제점

• 데이터베이스는 객체 구조와는 다른 데이터 중심의 구조를 가지기 때문에 객체를 데이터베이스에 직접 저장하거나 조회할 수 없다. 따라서 개발자가 객체지향 애플리케이션과 데이터베이스 중간에서 SQL과 JDBC API를 사용해 변환 작업을 해줘야 한다.
• Member 객체와 연관된 Team 객체를 사용할 수 있을지 없을지는 전적으로 사용하는 SQL에 달려있다. 이 방식의 가장 큰 문제는 데이터 접근 계층을 사용해 SQL을 숨겨도 어쩔 수 없이 DAO를 열어 어떤 SQL이 실행되는지 확인해야 한다는 것.
• 엔티티: Member나 Team 처럼 비즈니스 요구사항을 모델링한 객체 → 지금 처럼 SQL에 모든 것을 의존하는 상황에서는 개발자들이 엔티티를 신뢰하고 사용할 수 없다. DAO를 열어서 어떤 SQL이 실행되고 어떤 객체들이 함께 조회되는지 일일히 확인해야한다.
• 엔티티와 SQL, JDBC API 강한 의존관계 → 강한 의존관계 때문에 회원 조회할 때는 물론이고 회원 객체 필드 하나 추가할 때에도 DAO의 CRUD 코드와 SQL 대부분을 변경해야 하는 문제가 발생한다.

정리하자면,

• 진정한 의미의 계층 분할이 어렵다
• 엔티티 신뢰 할 수 없다
• SQL에 의존적인 개발을 피하기 어렵다

⇒ JPA를 통해서 해결하는 방법 : 객체를 DB에 저장하고 관리할 때 개발자가 직접 SQL을 작성하는 것이 아닌 JPA가 제공하는 API를 사용하면 된다.

• persist
• find
• 수정 : find → set
• 연관된 객체

패러다임의 불일치

• 현대의 복잡한 애플리케이션은 대부분 객체지향 언어로 개발한다.
• 애플리케이션은 자바라는 객체 지향 언어로 개발 / 데이터는 관계형 데이터베이스에 저장 ⇒ 패러다임 불일치
  • 여기에 너무 많은 시간과 코드를 소비한다
• 객체는 상속 ↔ 테이블은 상속 x / 슈퍼타입 - 서브타입 관계 사용하면 상속과 가장 유사한 형태로 설계 가능

⇒ JPA는 상속과 연관된 패러다임의 불일치 문제를 개발자 대신 해결해 준다. 개발자는 자바 컬렉션에 객체 저장하듯 JPA에 객체 저장하면 된다.

• 연관관계
  • 객체: 참조를 사용해 참조에 접근해 연관된 객체 조회
  • 테이블: 외래키를 사용해 다른 테이블과 연관관계를 가지고 join을 사용해 연관된 테이블 조회
  • 차이점 : 객체는 단방향 / 테이블은 양방향 모두 가능
  • 객체를 테이블에 맞추어 모델링하면, Member 객체에서 TeamId를 필드로 가지고 있다면, 소속된 팀을 조회하는 할때 SQL로는 조인으로 외래키 값을 사용해 조회할 수 있지만, 객체 지향적인 방법은 참조를 이용해 member.getTeam() 을 통해 Team 객체를 조회하는 방법이다. but 외래 키까지 관계형 데이터베이스가 사용하는 방식에 맞추면 Member 객체와 연관된 Team 객체를 참조 통해 조회 할 수 없다. ⇒ 객체지향의 특징을 잃게 된다.
• JPA는 연관관계와 관련된 패러다임의 불일치 문제를 회원과 팀 관계 설정하고, 회원 객체를 저장하면 된다.
  • JPA는 team의 참조를 외래 키로 변환해서 적절한 INSERT SQL을 DB에 전달
  • 객체 조회 시 외래 키를 참조로 변환하는 일도 JPA가 처리해 준다.