계속 사용을 하고 있는 기술이지만, 기본기를 잊는 것 같아 다시 복습을 하며 기록하고자 합니다.
김영한님이 쓰신 '자바 ORM 표준 JPA 프로그래밍' 책을 기준으로 정리하겠습니다.
🌱 github : https://github.com/KyungSik9870/jpa_study
먼저 JPA의 개념부터 잡고가겠습니다. 그리고 글 마지막에 실제로 써보면서 느낀점을 써보겠습니다.
JPA (Java Persistence API)
Java 의 ORM 기술 표준
그렇다면 ORM 은 무엇인지 부터 알아야 합니다.
ORM 이란 Object Relational Mapping 으로, 객체와 관계형 데이터베이스를 매핑 한 것을 말합니다. ORM Framework 은 객체와 테이블을 매핑하여 패러다임의 불일치를 개발자 대신 해결해줍니다.
예를 들어, 프레임워크를 사용하면 객체를 데이터베이스에 저장할 때, 개발자가 직접 insert문을 작성하는 것이 아니라 ORM 프레임워크가 적절한 insert 문을 작성해 데이터 베이스에 저장해줍니다.
ORM 프레임워크는 패러다임의 불일치 문제들을 해결해주고, CRUD의 기능을 강력히 제공해줍니다. Java 의 ORM 표준인 JPA도 위의 그림에서와 같이 객체와 데이터베이스의 데이터 사이의 불일치를 해결해주고, Entity 를 분석하여 Insert 문을 작성하고, 조회의 결과를 다시 Object 로 매핑해주는 기능을 제공해주고 있음을 알 수 있습니다.
JPA 를 사용하는 이유?
* 생산성
JPA 를 사용하면 자바 컬렉션에 객체를 저장하듯이 데이터를 저장 할 수 있습니다. 조회의 경우도 마찬가지입니다. CRUD 의 과정을 개발자가 쿼리를 작성하지 않고 처리할 수 있습니다.
* 유지보수
SQL을 직접 다루게 되면, 엔티티에 필드를 하나만 추가하더라도 모든 쿼리를 다 수정해야 합니다. 하지만 JPA를 사용하게 되면 이런 과정을 JPA 가 대신 처리해주므로 개발자가 수정해야할 소스가 줄어들고, 이는 실수가 줄어드는 효과를 가집니다.
* 패러다임의 불일치 해결
관계형 데이터베이스를 객체의 형태로 다루면서 나타나는 패러다임의 불일치를 연관관계의 매핑으로 해결 할 수 있습니다.
* 성능
JPA 는 다양한 성능 최적화를 제공합니다. 특히 쿼리의 실행계획 최적화와 개발자가 코드내에서 할 수 있는 다양한 성능 최적화를 다룰 수 있어 장점이 있습니다.
* 데이터 접근 추상화와 벤더 독립성
JPA는 Dialect 라는 추상화된 데이터 접근 계층을 제공해서 특정 데이터베이스에 종속되지 않도록 합니다.
JPA 의 기본 개념과 사용하는 이유(장점) 에 대해서 한번 정리를 해보았는데, 실제 사용하면서 느낀점들에 대해서 적어보려고 합니다.
먼저, JPA 는 사용을 해보며 위에서 언급한 장점들을 바로 느끼게 됩니다. 특히, 전에 쿼리를 중심으로 설계를 하고 특히 특정 벤더에 종속적인 쿼리를 만들던 회사에 근무하던 적이 있습니다. 그때 고객사 요청으로 벤더를 변경해야 됐었는데, 이미 특정 벤더에 종속적인 쿼리를 만들어 놓은 상태라 해당 요청을 거절해야만 했던 일이 떠오릅니다.
JPA 를 사용했다면 단지 설정파일의 코드 몇줄을 변경하는 것으로 끝나는 일이었을 겁니다. 그 외에도 JPA를 사용하면서 쿼리를 작성하는 일이 줄어 도메인로직에 더 집중할 수 있고, 객체로 관리되는 데이터에 여러가지 로직을 적용할 수 있다는 점에서 이점이 있었습니다.
하지만, 불편한 점도 없다고 할 수는 없습니다. JPA 를 사용하다보면 조건이 많은 쿼리, 연산이 있는 쿼리, join 이 많을 때 와 같이 불편한 상황도 있었습니다. 물론 QueryDsl 과 같은 기능을 사용하면서 해결할 수 있고, NativeQuery 를 작성할 수도 있습니다. 이렇게 복잡한 쿼리를 필요로 할 때, 분명 JPA는 한계를 가진다는 생각이 듭니다.
또한 러닝커브가 높다고 생각이 듭니다. (높다는 표현이 틀린 것 같지만 적당한 단어를 모르겠음 🤔)
배우기 어렵다는 뜻인데, 처음에 패러다임의 불일치와 연관관계 매핑을 생각하며 어려워지는 것 부터 시작입니다. 실제로 쿼리만 작성해오던 사람에게 '이제 JPA를 사용할까 하는데 공부해오세요.' 라고 한다면 꽤나 힘들어 할 것 입니다. 특히 도메인 설계와도 연결 지을 수 밖에 없어서 더 어렵다고 느껴집니다.
마지막으로는 연관관계에 대한 고찰입니다. 단방향, 양방향의 연관관계들이 있고 이를 잘 생각하며 설계를 한다고 하지만, 많이 조회되는 데이터인지 변경이 자주 일어나는지 등등 다양한 이유로 이 관계들에 대해서 다시 고민할 일들이 생겼습니다. 엔티티 객체를 그대로 사용하지 않고, DTO 형태의 새로운 클래스를 만들때 어쩔 수 없는 코드의 중복들도 존재했습니다.
하지만 이런 고민해볼 부분이 있지만 분명 좋은 기술이고, 이미 검증받은 기술이라고 생각합니다. 저도 어느샌가 도메인 로직에 더 집중되며 클린한 코드를 만드는데 집중하고 있습니다.
이 글 이후에 JPA 를 계속 복습하고 또 지식을 채워보겠습니다. 👍
'BackEnd > JPA' 카테고리의 다른 글
[JPA] 양방향 연관관계 & 연관관계의 주인 (1) (0) | 2022.05.09 |
---|---|
[JPA] 연관관계 매핑 : 기본 (2) (0) | 2022.05.08 |
[JPA] 연관관계 매핑 : 기본 (1) (0) | 2022.05.08 |
[JPA] 영속성 컨텍스트의 특징 (0) | 2022.05.04 |
[JPA] 영속성 관리 (0) | 2022.05.03 |