사내 자바 프로젝트 템플릿 경우,
Spring boot 어플리케이션에서 DB Access layer 및 쿼리는 Mybatis를 사용하고 있습니다.
Mybatis는 SQL Mapper 로써, 자바객체를 실제 SQL 문에 연결해주는 역할을 합니다.
BOQ처럼 DB 스크립트에 비즈니스 로직이 있는 경우나,
통계/데이터분석과 같은 복잡한 쿼리를 사용할 때 유리합니다.
그래서 우리에게 익숙한 Monolic한 서비스(=통짜로 한개 어플리케이션)을 만들때
DB 중심 설계와 비즈니스 로직을 SQL로 처리를 해야만 한다면, Mybatis를 대체할 만한게 딱히 없긴 합니다.
한편,
제가 사내 자바 프로젝트(Mybatis + 3단 Layer-Controller/Service/Dao) 를 실제 운용해보면서 느낀점을 말씀드리겠습니다.
- 비즈니스 로직 및 Transaction 처리를 Service 레이어가 담당하고 있지만, 최종 쿼리(SELECT/UPDATE/DELETE)를 확인 하기 위해 매핑된 xml 쿼리까지 찾아봐야 로직 파악이 가능했습니다.
- 이렇게 단순 쿼리를 하기 위해 매번 xml 구문을 확인하고 만들어야 했습니다.
- DB 중심 설계가 되다 보니 자바 객체들은 데이터를 담고 옮겨주는 그릇 역할이 주된 목적이었습니다.
따라서 객체지향 언어인 자바를 다루지만 설계에 있어서 객체 간의 관계는 거의 무시되는 느낌이었습니다.
객체 모델링 관점으로,
이러한 이슈는 관계형 데이터베이스가 지향하는 것과는 근본적인 패러다임 불일치에 따른 사항이라,
객체 구조를 테이블 구조에 저장하는 것에는 한계가 있기 때문에
Mybatis 를 사용하는 대부분 프로젝트는 당연시 되는 문제이긴 합니다.
또한,
사용하고 운용 해보신 분들은 단순한 CRUD 작업 시, 그 지루함과 노가다를 많이 느꼈을 것이라고 생각됩니다.
MEMO 라는 테이블에 CRUD(쓰기/읽기/수정/삭제) 기능으로 계층별(Controller/Service/DAO/xml) 로 다 구현했는데,
MEMO 테이블에 컬럼이 추가되면 변경되어야 하는 파일들이 한두개가 아닙니다.
이렇게 한마디로 요약 할 수 있을 것 같습니다.
"왜 객체 지향의 장점을 포기하고 객체를 단순히 테이블에 맞추어 데이터 전달 역할만 하도록 개발해야 할까?"
이 의문은 많은 개발자들이 예전부터 고민을 했었고,
그래서 나온 기술이 바로 ORM(Object-relational mapping) 입니다. (닷넷 진영은 Entity Framework가 ORM 입니다)
Mybatis는 ORM이 아닌가요?
ORM이 아닙니다. SQL mapper 입니다.
ORM은 관계형 데이터베이스의 ‘관계’를 Object에 반영하자는 것이 목적이라면,
SQL Mapper는 단순히 필드를 매핑시키는 것이 목적이라는 점에서 지향점의 차이가 있습니다.
자바 진영의 ORM 역사를 간단히 보면 다음과 같습니다.
JPA (Java Persistence API) 란,
자바에서 데이터를 DB에 저장(=영속성, persistence) 시키기 위한 API 라고 보면 됩니다.
참고로, JPA는 표준 인터페이스 모음집, 즉 동작하는 소스가 아니라 Interface일 뿐입니다.
이 인터페이스에 대한 구현체가 3가지 정도 있는데,
가장 많이 사용되는 구현체가 바로 Hibernate입니다.
JPA를 보다보면 Hibernate가 자주 등장하는데, 우리는 API가 관심있지, 복잡한 내부 구현체인 Hibernate까지 들여다 볼필욘 없을 것입니다.
그러면 왜 JPA를 사용해야 하는가?
초기에 모든 요구사항을 수집하고 설계하고 개발하고 테스트하던 아주 긴 호흡의 개발 방법이 현재 통하고 있나요?
실제 사용자의 목소리를 듣고 이를 실시간으로 반영해야 합니다. 그리고 요구사항은 언제나 변할 수 있습니다.
DB 구조 중심으로 설계된 어플리케이션에서 DB 구조가 살짝이라도 바뀌게 되면 그 여파는 어마어마한 건 모두가 알고 있습니다. 그래서 DB 의존성을 제거하려는 노력으로 JPA가 생긴 이유입니다.
따라서, SQL 중심 개발에서 객체 중심 개발이 가능해집니다.
이는 객체와 관계형 데이터베이스간 패러다임 불일치를 해결했기 때문입니다.
그러면 뭐가 좋죠?
개발자는 SQL 스크립팅에는 거의 관여하지 않고 객체 설계와 자바 어플리케이션(Spring boot) 개발에 집중할 수 있어서 더욱 말랑말랑한 소프트웨어를 만들 수 있습니다.
예를 들어보겠습니다.
아래와 같이 객체(Entity) 모델링을 한다면,
JPA를 통해 DB 테이블 관계도 동일하게 제어가 가능해집니다.
(어떻게 가능한지에 대한 설명은.... 좀더 간단한 샘플소스로 2탄에서 설명 하겠습니다)
그리고 생산성과 유지보수 면에서 상당히 유리할 것으로 보입니다.
이것도 2탄 샘플소스를 보면서 설명 드리겠습니다.
또 있습니다.
DB 벤더사에 독립적으로 개발이 가능합니다.
예를 들어 JPA를 사용하면
로컬개발환경은 인메모리 db인 H2 쓰고,
QA는 무료인 MySQL/MariaDB 쓰고,
LIVE는 Oracle 데이타 베이스 사용하는데에 있어서 자유롭습니다.
혹시 현재 자바 프로젝트 템플릿 및 mybatis 사용하는데 전혀 문제 없는데? 라고 하시는 분은...
아무 도움 되지 않는 글이었을 것입니다.
한편, 내면의 변화가 느껴시진 분들 중에
JPA를 한번도 들어본적 없거나
들어는 봤는데, 아직 학습이나 사용은 안해봤다면 이런 의문이 들것입니다.
SQL 쿼리문 작성이 필요없다고?
그러면 SQL은 몰라도 돼?
중요한! 성능은?
트랜잭션 처리는?
러닝 커브는?
