1. [JPA] 사용 경험

프로그래밍|2017. 7. 21. 13:38

이전 프로젝트에서 처음으로 JPA를 사용해 보았다.

실무에 적용하기 전에는 JPA가 무엇인지 궁금하여 테스트 삼아 몇 번 공부한게 전부였다.

허나 실무에서 직접 사용하려고 했을 때의 중압감은 사뭇 다르다는 것을 느꼈다.

이유인 즉슨, 다음의 항목들에 대해서 이해를 하고 있어야 실무에 도입해도 큰 문제가 없다고 들었기 때문이다.

  • JPQL 이란?
  • 즉시, 지연 로딩 전략
  • 영속성 컨텍스트에 대한 이해
  • 자동 변경 감지
  • 언제 영속성 컨텍스트가 flush 되는가?
  • 연관관계 매핑중에 mappedBy, inverse 이해
  • OSIV 란?
  • N+1 질의 문제 (query)
  • 쓰기 지연


솔직히 위의 항목 중 어느 한 가지도 제대로 이해하지 못한 상태였다.

그렇게 JPA에 대한 상세 지식이 없는 상태에서 개발을 진행하게 되었고, 어찌됐든 개발이 완료되기 전에는 위의 것들을 모두 이해해 보자라고 다짐했다.


프로젝트가 진행되는 기간에 JPA 책을 대여하여 틈틈이 읽고 테스트 코드를 작성하며 학습해 나갔다.

그렇게 하여 개발이 끝나고 오픈이 완료된 이 시점에는 JPA를 사용함에 있어 두려움이 없는 수준까지 끌어 올릴 수 있게 되었다.


JPA를 사용하고 나니 왜 다들 JPA가 좋다고 하는지 그제서야 알게 되었다.

이건 개발자들이 직접 JPA를 실무에 적용해 보고 사용해 봐야 이해할 수 있을 것 같다. 왜냐하면 나 또한 JPA를 굳이 써야돼? 라는 생각을 가지고 있었으니..


실무에서 MyBatis와 JPA를 각각 써본 개발자로써 어떤 차이점이 있는지 비교를 해보면

MyBatis로 개발을 했을 때에는 크게 다음의 4가지에 집중을 많이 했다.

가장 힘들고 지겨웠던 작업이 화면에 따라 쿼리를 지속적으로 만들어야 한다라는 점이다.

  • 화면에 따른 select, update, insert, delete 쿼리 생성 (XML파일)
  • 쿼리 결과 데이터를 저장하는 POJO 클래스 생성
  • DAO (Data Access Object) 클래스 생성
  • 테이블의 컬럼이 바뀌는 경우가 별로 없지만 변경이 일어났을 시 관련된 쿼리를 모두 변경해 줘야 함 (리팩토링 불가)


이에 반해 JPA를 사용했을 때에는 다음과 같았다.

  • 테이블이 10개라면 10개의 entity만 생성하면 됨. (도메인 오브젝트 중심 개발)
  • 엔티티를 생성하고 각각의 객체 연관관계 설정을 진행 (@OneToOne, @ManyToOne, @OneToMany 와 같은 설정)
  • 테이블 컬럼명이 바뀌면 리팩토링으로 한번에 해결
  • 코드양이 MyBatis 대비 어림잡아 1/3로 줄음

 

테이블과 엔티티 클래스가 1:1 매핑이 되는 구조이기에 화면이 추가된다고 해서 엔티티를 더 만들어야 한다라는 조건이 없다.

그저 객체 연관관계 설정을 잘하여 필요한 데이터가 있으면 객체를 타고 다니며 데이터를 뿌려주면 된다. "객체를 타고" 라는 표현을 "객체 그래프 탐색"이라고 부른다.


위와 같은 차이라면 JPA를 안쓸 이유가 없다.

하지만 사용하기 쉽고 편리하다고 하여 그저 막 쓸 수 있는 것이 아니기에 위에서 나열한 알아야 할 것들을 이해하고 있어야 한다라는 점이다.

요즘 프로그래밍의 트랜드가 반복적이고 불편한 것들은 숨기고 이를 설정으로만 관리되도록 하고 있다. 이말은 개발자들이 직접 개발은 하지 않지만 동작하는 방법에 대해서는 이해하고 있어야 한다라는 점이다. 이런 동작 원리를 모르고 있으면 어떤 얘기치 않는 상황에서 디버깅하기 쉽지 않을 것이다.

 

여튼 지금까지 개발과 학습을 하면서 테스트 코드를 작성하였으니 이제는 블로깅을 통해서 내용을 정리해 보려고 한다.

정리를 진행하다 보면 자연스레 더 알아야 할 부분들이 있을 것이고 생각 정리가 잘 될 것이다.

댓글()