Why Use JPA?

1. Use Directly SQL

1.1. Repeat, Repeat, Repeat...

• Read
  • 등록용 SQL 작성 -> JDBC를 활용한 SQL 실행 -> 결과 Mapping
• Create, Update, Delete
  • 관련 동작 SQL 작성 -> 객체 값을 SQL에 전달 -> JDBC를 활용한 SQL 실행

각 테이블, 동작마다 너무 많은 SQL, JDBC API 코드가 필요!

1.2. SQL-Dependent Development

• Entity 신뢰가 어려움
  • DAO를 일일히 확인하며 SQL과 객체 조회 확인이 필요!
• 진정한 의미의 계층 분할이 어려움

2. Paradigm Mismatch

• 객체와 RDB는 지향하는 목정이 서로 다르므로 기능과 표현 방법이 다르다
  -> 이를, 객체와 RDB의 패러다임 불일치 문제라고 한다!

2.1. 상속

• 객체는 상속 기능 ⭕ / but, 테이블은 상속 기능 ❌ or 다름

• SQL만 사용할 때, 예시

  • 코드

    abstract class Sample {
      Long id;
      String string;
      int integer;
    }
    class Sample_A extends Sample {
      String a;
    }
    class Sample_B extends Sample {
      String b;
    }

  • 구현체 저장 시, 객체를 분리해서 SQL를 두 개 만들어야함

    Sample, Sample_A | Sample, Sample_B

소모되는 시간이 너무 많이 듬

2.2. 연관관계

• 객체는 참조를 이용해 연관관계, 참조에 접근해서 조회
• 테이블은 외래 키를 사용해 연관관계, 조인을 사용해서 조회

2.2.1. 객체를 테이블에 맞추어 모델링 (Use ID)

class Member {
  Long id;
  Long teamId;
  String name;
}

class Team {
  Long id;
  String name;
}

• 객체
  • 테이블 저장, 조회는 편리
  • but, 객체는 연관된 객체 참조 ❌ -> 연관 객체 참조 조회 ❌

객체 지향의 특징을 잃어버림

2.2.2. 객체지향 모델링 (Use 객체)

class Member {
  Long id;
  Team team;
  String name;
}

class Team {
  Long id;
  String name;
}

• 연관 객체 참조를 통한 연관 팀을 조회
• but, 객체 -> 테이블 저장, 조회가 쉽지 않음
  • 객체는 use 참조, 테이블은 use 외래 키 -> 개발자가 중간 변환

소모되는 시간이 너무 많이 듬

2.3. 객체 그래프 탐색

• SQL을 직접 다루면 SQL에 따라서 탐색 범위가 정해짐

2.4. 비교

• DB는 기본 키의 값으로 Row를 구분
• 객체는 동일성 비교, 동등성 비교
  • 동일성 비교 (==)

    객체 인스턴스의 주소값 비교

  • 동등성 비교 (eqauls())

    객체 내부의 값 비교

객체와 DB의 값 비교는 차이가 있음!