문제점
아무리 MyBatis를 통해 DB연동에 필요한 부수적인 코드를 숨기고, 쿼리문과 자바코드를 분리해 작성하고 관리하면서 결합도를 낮춘 구성이 가능해졌다 문제점을 존재했습니다.
일단 쿼리문을 개발자가 직접 작성해 관리하면서 메소드의 동작에 이상이 생기거나 에러가 발생하면 자바코드가 아닌 쿼리문을 수정하면서 에러를 해결하거나 성능 최적화를 하는 소요는 피할 수 없었습니다.
게다가 객체 지향스러운 코드를 1순위로 지향하면서 코드를 작성한다 하더라도 테이블과 객체의 구조적인 차이로 인해 실제로 데이터가 저장되는 DB 구조에 의존된 코드 구성을 할 수 밖에 없었습니다.
저는 이러한 문제점을 JPA를 통해 해결해 보고자 했습니다.
해결방안
JPA
JPA는 한마디로 자바 표준 ORM(Object Relational Mapping)입니다. 즉, 객체와 관계형 DB를 매핑해주는 여러 프레임워크 중 표준으로 채택된 프레임워크라고 할 수 있습니다. 이전에 사용되는 MyBatis는 SQL Mapper로 테이블이 아닌 쿼리문을 매핑해 객체로 치환해주는 역할을 했다고 보면 두 기술의 차이점이 명확해집니다.
다시 말해 이전에 SQL을 직접 작성하고 이에 따라 조작될 데이터를 객체로 매핑하는 것이 아닌 객체를 컬렉션에 저장하듯이 메소드를 실행시키면 자동으로 이에 맞는 쿼리문을 생성해 DB에 저장시켜주는 역할을 하는 것이 ORM이며 그 중 표준으로 사용되는 녀석을 JPA라고 볼 수 있습니다.
JPA의 장점
생산성
JPA를 통해 컬렉션에 객체를 저장하듯이 메소드만 구성하면 JPA가 DB에 쿼리문을 생성해 넘겨주기 때문에 반복적으로 작성해야 했던 쿼리문에 대한 코드 작성을 안할 수 있어 생산성을 높일 수 있습니다.
유지보수
생산성과 같은 맥락으로 쿼리문에 대한 작업을 JPA가 대신 해주기 때문에 유지보수적인 측면에서도 코드의 양이 줄고 간편해져 매우 유리해질 수 있습니다.
패러다임 불일치 해결
객체 패러다임과 테이블 패러다임에서 생성되는 차이점으로 인해 JPA를 활용하기 이전의 코드는 테이블 구조에 의존적인 코드를 작성하기 쉬웠습니다. 하지만 JPA는 이 두 차이에서 오는 여러 문제를 대신 해결해주고 숨겨주기 때문에 JPA를 사용하는 개발자는 객체 지향스러운 코드를 작성하기 위해 집중할 수 있습니다. 이를 통해 객체 지향 언어가 주는 장점을 활용할 수 있는 코드 작성에도 매우 유리해질 수 있습니다.
성능
JPA는 영속성 콘텍스트를 기반으로 1차 캐시, 쓰기 지연, 변경 감지 등 성능 최적화를 위해 제공되는 여러 기능들이 있고, 이를 정확히 이해하고 활용한다면 성능을 높일 수 있는 장점을 가지고 있다고 볼 수 있습니다.
데이터 접근 추상화 및 벤더 독립성
JPA는 어플리케이션과 DB 사이의 연결고리 역할을 수행하면서 DIP를 지킨 구조로 구성되어 있어 DB의 종류와 상관없이 JPA를 통해 DB를 연동시킬 수 있습니다. 즉 어플리케이션 입장에선 DB의 종류의 차이로 오는 기술적 차이에 상관없이 변경할 수 있고 교체에 매우 유리한 구조를 설계할 수 있습니다.
마치며
이처럼 저는 JPA라는 표준 ORM 프레임워크를 도입하면서 DB와의 연동으로 인해 발생한 쿼리문에 대한 의존성이 강한 코드를 제거하고 OOP의 장점을 최대한 살리면서 유지보수 측면에서 강점을 가지고 확장에 유리한 설계를 할 수 있도록 했습니다.
참고자료
http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 (자바 ORM 표준 JPA 프로그래밍(김영한님)
