Spring JPA - DoDaek/freelec-springboot2-webservice GitHub Wiki

• 현대의 웹 어플리케이션에서 관계형 데이터베이스 ( RDB, Relational Database ) 는 빠질 수 없는 요소
• 객체를 관계형 데이터베이스에서 관리하는 것이 무엇보다 중요
• 관계형 데이터베이스가 계속해서 웹 서비스의 중심이 되면서 모든 코드는 SQL 중심이 되어갑니다.

---

• 현업 프로젝트 대부분이 애플리케이션 코드보다 SQL로 가득하게 된 것

  • 관계형 데이터베이스가 SQL만 인식할 수 있기 때문
  • 각 테이블마다 기본적인 CRUD ( Create, Read, Update, Delete ) SQL을 매번 생성해야 한다.
  • 예를 들어 User 객체를 테이블로 관리한다면

  insert into user ( id, name, ... ) values ( ... );
  select * from user where ...;
  update user set ... where ...;
  delete from user where ...;
  

---

• 개발자가 아무리 자바 클래스를 아름답게 설계해도, SQL을 통해야만 데이터베이스에 저장 및 조회

• 실제 현업에서는 수십, 수백 개의 테이블이 있는데, 이 테이블의 몇 배의 SQL을 만들고 유지보수해야만 한다.

  → 스트레스

• 단순 반복 작업의 문제 외에도 한 가지 문제가 더 있다.

  • 패러다임 불일치 문제
  • 관계형 데이터베이스는 어떻게 데이터를 저장할지에 초점이 맞춰진 기술
  • 반대로 객체지향 프로그래밍 언어는 메시지를 기반으로 기능과 속성을 한 곳에서 관리하는 기술

---

• 관계형 데이터베이스와 객체지향 프로그래밍 언어의 패러다임이 서로 다른데, 객체를 데이터베이스에 저장하려고 하니 여러 문제가 발생합니다. → 패러다임 불일치
• 객체지향 프로그래밍에서 부모가 되는 객체를 가져오려면 어떻게 해야할까요?

User user = findUser();
Group group = user.getGroup();

• 누구나 명확하게 User와 Group은 부모-자식 관계임을 알 수 있습니다.
• User가 본인이 속한 Group을 가져온 코드이기 때문입니다.
• 하지만 여기에 데이터베이스가 추가되면 다음과 같이 변경됩니다.

User user = userDao.findUser();
Group group = groupDao.findGroup(user.getGroupId());

• User 따로, Group 따로 조회하게 됩니다.

• User와 Group이 어떤 관계인지 알 수 있을까요?

• 상속, 1:N 등 다양한 객체 모델링을 데이터베이스로는 구현할 수 없습니다.

  → 웹 애플리케이션 개발은 점점 데이터베이스 모델링에만 집중하게 됩니다.

---

• JPA는 서로 지향하는 바가 다른 2개 영역 ( 객체지향 프로그래밍 언어와 관계형 데이터베이스 ) 을 중간에서 패러다임 일치를 시켜주기 위한 기술
• 개발자는 객체지향적으로 프로그래밍을 하고, JPA가 이를 관계형 데이터베이스에 맞게 SQL을 대신 생성해서 실행합니다.
• 개발자는 항상 객체지향적으로 코드를 표현할 수 있느니 더는 SQL에 종속적인 개발을 하지 않아도 됩니다.

---

Spring Data JPA

• JPA는 인터페이스로서 자바 표준명세서입니다.

• 인터페이스인 JPA를 사용하기 위해서는 구현체가 필요합니다.

  → 대표적으로 Hibernate, Eclipse Link 등

• 하지만 Spring에서 JPA를 사용할 때는 이 구현체들을 직접 다루진 않습니다.

  → 구현체들을 좀 더 쉽게 사용하고자 추상화시킨 Spring Data JPA라는 모듈을 이용하여 JPA 기술을 다룬다.

• Hibernate를 쓰는 것과 Spring Data JPA를 쓰는 것 사이에는 큰 차이가 없습니다.

• 그럼에도 스프링 진영에서는 Spring Data JPA를 개발했고, 이를 권장하고 있습니다.

• 한 단계 더 감싸놓은 Spring Data JPA가 등장한 이유

  1. 구현체 교체의 용이성
  2. 저장소 교체의 용이성

구현체 교체의 용이성

• Hibernate 외에 다른 구현체로 쉽게 교체하기 위함

• Hibernate가 언젠가 수명을 다해서 새로운 JPA 구현체가 대세로 떠오를 때, Spring Data JPA를 쓰는 중이라면 아주 쉽게 교체할 수 있습니다.

• Spring Data JPA 내부에서 구현체 매핑을 지원해주기 때문입니다.

  → 자바의 Redis 클라이언트가 Jedis에서 Lettuce로 대세가 넘어갈 때 Spring Data Redis를 쓰신 분들은 아주 쉽게 교체를 했습니다.

저장소 교체의 용이성

• 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함

• 서비스 초기에는 관계형 데이터베이스로 모든 기능을 처리했지만, 점점 트래픽이 많아져 관계형 데이터베이스로는 도저히 감당이 안 될 때가 올 수 있습니다.

  → MongoDB로 교체가 필요하다면 개발자는 Spring Data JPA에서 Spring Data MongoDB로 의존성만 교체하면 됩니다.

  → Spring Data의 하위 프로젝트들은 기복적인 CRUD의 인터페이스가 같기 때문입니다.

---