김영한 님의 자바 ORM 표준 JPA 프로그래밍 책을 읽고 정리한 내용입니다.

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

1️⃣ 반복, 반복, 그리고 반복

: 객체를 데이터베이스에 CRUD하려면 너무 많은 SQL과 JDBC API를 코드로 작성해야 한다.
그리고 테이블마다 이런 비슷한 일을 반복해야 한다.

2️⃣ SQL에 의존적인 개발

회원 객체를 관리하는 MemeberDAO에 회원의 연락처도 추가해야 하는 상황을 가정해보자.
회원의 연락처를 추가하려면,
1. 회원 클래스(Member)에 tel 필드를 추가
2. 연락처를 저장할 수 있도록 INSERT SQL 수정
3. 회원 객체의 연락처 값을 꺼내 등록 SQL에 전달
4. 회원 조회용 SQL 수정 (연락처 추가)
5. 연락처의 조회 결과를 Member 객체에 추가로 매핑
...

이렇게 하나의 정보를 수정하기 위해 많은 코드의 수정이 필요하다.

두 번째로, 하나의 객체가 다른 객체가 연관되어(ex. Member 객체에 team 필드 추가) 코드에 에러가 발생했을 때 DAO를 열어서 SQL을 확인하고 나서야 그 원인을 알 수 있다.

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

• 엔티티 : Member나 Team 클래스처럼 비즈니스 요구사항을 모델링한 객체

JPA는 어떻게 문제를 해결할까? 🤔

저장 기능

jpa.persist(member); // 저장

persist() 메소드를 사용해서 객체를 데이터베이스에 저장한다.

조회 기능

String memberId = "helloId";
Member meber = jpa.find(Member.class, memberId); // 조회

find() 메소드를 사용하여 객체 하나를 데이터베이스에서 조회한다.

수정 기능

Member member = jpa.find(Member.class, memberId);
member.setName("이름 변경");

별도의 수정 메소드를 제공하지 않는다.
대신 객체를 조회해서 값을 변경하면 트랜젝션을 커밋할 때 데이터베이스에서 적절한 UDPDATE SQL이 전달된다.

연관된 객체 조회

Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam(); // 연관된 객체 조회

연관된 객체를 사용하는 시점에서 적절한 SELECT SQL을 실행한다.
이렇듯 JPA는 SQL을 개발자 대신 작성해서 실행해주는 것 이상의 기능을 제공한다.

1.2 패러다임의 불일치

애플리케이션은 발전하면서 그 내부의 복잡성도 점점 커진다.
지속 가능한 애플리케이션을 개발하는 일은 끊임없이 증가하는 복잡성과의 싸움이다.

객체는 속성(필드) 과 기능(메소드) 을 가진다.
객체가 단순하면 객체의 모든 속성 값을 꺼내서 파일이나 데이터베이스에 저장하면 되지만, 부모 객체를 상속받았거나, 다른 객체를 참조하고 있다면 객체의 상태를 저장하기 쉽지 않다.
ex) 회원 객체가 팀 객체를 참조하고 있을 때, 회원 객체를 저장하려면 팀 객체도 함께 저장하여야 한다.

관계형 데이터베이스는 데이터 중심으로 구조화 되어 있고, 집합적인 사고를 요구한다.
객체지향에서 이야기하는 추상화, 상속, 다형성의 개념이 없다.

객체와 관계형 데이터베이스가 지향하는 목적이 달라 패러다임의 불일치가 발생한다.

연관 관계

• 객체 - 참조를 사용해서 다른 객체와 연관 관계를 가지고 참조에 접근해서 연관된 객체를 조회
  • 참조가 있는 방향으로만 조회 가능
• 테이블 - 외래키를 사용해서 다른 테이블과 연관 관계를 가지고 조인을 사용해서 연관된 테이블을 조회
  • 외래키로 양방향 조회 가능