해당 내용은 이동욱님 저서 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스'를 공부하며 정리한 내용입니다.
필자가 스프링을 배울 때는 iBatis와 같은 SQL Mapper를 이용해서 DB의 쿼리를 작성했습니다.
그러다 보니 실제로 개발하는 시간보다 SQL을 다루는 시간이 더 많았습니다.
이것이 이상하게 느껴졌습니다.
분명 “객체지향 프로그래밍을 배웠는데 왜 객체지향 프로그래밍을 못하지?”라는 생각을 계속했습니다.
객체 모델링보다는 테이블 모델링에만 집중하고, 객체를 단순히 테이블에 맞추어 데이터 전달 역할만 하는 개발의 형태는 분명 기형적인 형태였습니다.
저자 이동욱님의 말이다. 그리고 나도 이런 생각을 한적이 있어 이 내용에 크게 공감한다.
C언어로 처음 개발 공부를 시작한 나는 처음 Java를 배울 때 아주 불편해했다. C에서는 간단한 함수면 끝나던 작업이 '객체'라는 개념 때문에 코드가 길어진게 그 이유였는데, OOP를 공부하면서 부터는 Java에 흥미를 느끼기 시작했다.
하지만 Spring으로 웹 개발을 시작하고 프로젝트를 수행하다보니, DB에서 데이터를 CRUD하는데 초점이 맞춰져있고 객체도 DB 테이블에 따라 설계했다. 실제로 테이블 설계에는 아주 오랜 시간이 걸렸지만, 객체 설계는 그저 설계해둔 테이블의 컬럼을 받을 필드들과 몇 개의 데이터 가공을 위한 메서드들을 만들고는 끝이었다. OOP는 스프링의 구조를 잡을 때만 쓰였고, 저자 이동욱님의 말대로 ‘객체를 단순히 테이블에 맞추어 데이터 전달 역할만 하는 형태'라고 느꼈다. 그래서 ‘웹 백엔드는 매력이 없다'라고 생각한 적도 있었다.
JPA를 통해 이런 부분을 해소할 수 있다고 하니 앞으로 JPA도 열심히 공부해봐야겠다!
관계형 데이터베이스가 웹 서비스의 중심이 되며 모든 코드는 SQL 중심이 되었다.
- 관계형 데이터베이스(RDB, Relational Database)의 사용량이 압도적으로 많다.
- RDB는 SQL만 인식 가능하다.
—> 프로젝트의 대부분이 애플리케이션 코드보다 SQL 위주가 된다.
이책에서는 이 것에 대한 해결책으로 JPA를 제시한다.
myBatis : SQL Mapper, 쿼리를 매핑한다.
JPA(Java Persistence API) : Object Relational Mapper, 객체를 매핑한다.
Spring Data JPA
인터페이스인 JPA를 사용하기 위한 구현체(Hibernate, Eclipse Link) 등을 더 쉽게 사용하기 위해 추상화시킨 모듈
Spring Data JPA 사용의 장점
- 구현체 교체의 용이성
Spring Data JPA 내부에서 구현체 매핑을 지원하기 때문에 추후 Hibernate외에 다른 구현체로 쉽게 교체가 가능하다. - 저장소 교체의 용이성
Spring Data의 하위 프로젝트들은 기본적인 CRUD 인터페이스가 같기 때문에 추후 관계형 데이터베이스 외에 다른 저장소(MongoDB 등)로 쉽게 교체가 가능하다.
