JPA
JPA(Java Persistence API)는 자바 진영의 ORM 기술 표준
- JPA가 제공하는 API를 사용하면 객체를 DB에 저장하고 관리할 때, 개발자가 직접 SQL을 작성하지 않아도 된다.
- JPA가 개발자 대신 적절한 SQL을 생성해서 DB에 전달하고, 객체를 자동으로 Mapping 해준다.
- JPA는 내부적으로 JDBC API를 활용하는데, 개발자가 직접 JDBC API를 활용하면 패러다임 불일치, SQL 의존성 등으로 인해 효율성이 떨어진다.
- 이 때, JPA를 활용한다면 모든 SQL에 대해 개발자 대신 JPA가 자동으로 해결해 준다는 점에서 생산성을 크게 높인다.
ORM
ORM(Object-Relational Mapping)은 객체와 관계형 DB를 매핑한다는 뜻
- ORM 프레임워크를 사용하면 객체를 마치 자바 컬렉션에 저장하듯 저장할 수 있고, 이에 대해 ORM 프레임워크가 적절한 SQL을 생성해서 DB에 객체를 저장해준다.
Hibernate
자바 진영의 다양한 ORM 프레임워크 중 가장 많이 사용되는 성숙한 프레임워크
- 이러한 Hibernate 기반으로 만들어진 ORM 기술 표준이 바로 JPA다.
- 즉, JPA라는 ORM 기술 표준을 구현한 것이 Hibernate이므로, JPA를 사용하려면 Hibernate를 사용하면 된다.
👍🏼 이를 통해, 개발자는 관계형 DB를 사용해도 객체지향 어플리케이션 개발에 집중할 수 있게 된다.
코멘트
JPA 공부를 본격적으로 해보려 책을 구매했다.
맵씨 프로젝트를 진행할 때 우리 팀은 JPA를 제대로 활용하지 못하고 JDBC와 SQL문을 직접 써가며 서버를 만들었다. 시간이 많이 부족했던 탓도 있었지만, 일단 JPA에 대한 개념 자체가 없어서 디버깅하면서도 심각하게 막막했던 기억이 난다. 개발 환경에 따라서도 에러가 났다가 안 났다가 하고, 아예 실행 자체가 안 되는데 기초 지식도 없으니 진짜 답답했다.
또한, 맵씨를 통해 하드코딩한 SQL문과 JDBC Template을 사용해가며 서버를 작성했을 때의 문제점을 여실히 느낄 수 있었다.
첫째는 SQL문에 있는 사소한 오타 따위가 디버깅 시간을 엄청나게 많이 잡아 먹는다는 것이었다.
내가 직접 한 줄 씩 타이핑한 쿼리인 만큼 실수가 필연적으로 존재할 수 밖에 없었는데, 그걸 팀원들이 이해하고 디버깅하는 것이 엄청난 시간 낭비로 느껴졌다.
둘째는 쿼리에 비즈니스 로직이 의존하게 된다는 점이었다.
관계형 DB의 테이블 형태와 객체 매핑이 힘들어지면서, 시간과 지식이 부족한 상태의 나는 비즈니스 로직을 코딩하기 쉬운 방향으로 바꾸자고 여러 번 요구하게 되었다. 그러면서 현타가 참 많이 왔는데, 구현을 못 할 정도로 개떡같은 DB와 코드를 짜 놓고 안 된다고 못 한다고 말하는 것이 나의 무능을 만천하에 알리는 것 같았기 때문이다..
하지만 이는 내 부족함도 있었지만, 실제로 코드가 복잡해질 수밖에 없었던 환경이기도 했다. JPA를 쓰면 확실하고 안전하게 객체 지향 코드를 짤 수 있지만, JDBC Template으로는 일일히 하위 개념들을 매핑을 했어야 했기 때문이다. 진짜 힘들었다..
셋째는 조금 다른 형태의 비슷한 쿼리들의 수정 작업이 끝이 없다는 점이었다.
특히 변경 사항이 생기는 경우 수정 쿼리를 여러 개 작성하고 추가하고 삭제하는 일을 반복했는데, 참 비효율적이고 재미없다는 생각을 많이 했다. 에러가 난 것도 아니고 테이블을 엎은 것도 아닌데 계속 비슷한 형태의 쿼리들을 바꾸고 있어서 지겹기도 했다. 그래서 더더욱 JPA를 써보고 싶다는 생각을 하게 된 것 같다.
암튼 이렇게 맵씨를 하면서 언젠가 JPA를 제대로 공부해서 멋드러지게 써먹어 보겠다는 다짐을 하게 되었고, 졸프 서버를 (내가 원하던 대로) 맡게 되면서, 열심히 공부할 기회가 생겼다. 혼자 프로젝트하면서 공부하면 흐지부지될 게 뻔하니까 지금 기회가 왔을 때 많이 바쁘더라도 열심히 해야 겠다.
