첫 포스트로 논란거리로 자주 오르락내리는 JPA 와 MyBatis에 대해 얘기하고자 한다.
관계형 데이터베이스(RDB)와 아키텍쳐
두개를 비교하기 전에 아키텍쳐 얘기를 먼저 해야할 것 같다.
엔터프라이즈 시스템에서 주요 데이터들은 장기적, 안정적으로 사용되어야 하므로 주로 RDB에 저장되었다. 이렇게 RDB를 데이터 저장소로 쓰면서 서비스의 대부분은 SQL을 다루는 작업이 되었고. 빠른 개발을 위해서 개발자들은 SQL에 집중을 했다. 프레임워크도 개발자의 빠른 개발과 유지보수에 대응하기 위해 관심사분리 (DB 필드명이나 테이블명이 바뀌는 등의 작업은 DAO 의 관심사가 X) 를 통해 SQL문을 코드로 부터 분리 하려는 시도를 하였고, 이런 시도 끝에 SQL구문을 Java에서 분리하는 작업이 이루어졌다.
분리작업은 초기에는 쿼리를 저장 프로시져에 넣거나 별도의 XML파일안에 쿼리문을 넣고 매핑시켜주는 방식으로 이루어졌다. 별도의 XML 파일안에 넣어 SQL과 객체를 Mapping시켜주는 역할을 하는 것중에 하나가 Mybatis 이다.
그렇게 분리작업을 마친 후 코드를 보니 3tier 구조에서 모든 레이어는 SQL or 저장 프로시져 기반으로 돌아가고, 심지어 프레젠테이션 레이어에서도 쿼리의 결과를 그대로 보여주는 역할만 하도록 돌아가게 되는 경우를 보게 되는데.. 이런 느낌의 아키텍쳐를 데이터 베이스 기반 아키텍쳐라고 볼 수 있다. 데이터 베이스 기반 아키텍쳐는 유닛테스트 불가. 트랜잭션 처리의 어려움. DB에 부하를 주는 등의 다양한 문제점을 가지고 있다.
이런 아키텍쳐의 문제점을 파악하고 저장프로시져 사용을 자제하고 복잡한 SQL 사용을 자제하면서 비지니스 로직을 서비스 레이어로 끌어 올리면
이제는 거대한 서비스 계층(fat service layer)를 만들게 된다. 이러한 경우에는 테스트를 작성하여 자동화된 테스트를 할 수 있고, 트랜잭션 처리도 서비스 레이어에서 할 수 있겠지만 어떠한 경우에는 쿼리를 사용하는 것보다 더 스파게티같은 코드가 나올 수 있고, 그로인해 장기적으로 코드를 발전시키기가 힘들다는 단점이 있을 수 있다.
객체지향 언어의 장점을 살리고, 위의 문제를 해결하기 위해서 생각해 낸것이 바로 오브젝트 지향 아키텍쳐인데, 이 아키텍쳐에서는 도메인 모델을 반영하는 오브젝트 구조를 만들어놓고 이를 계층간 통신에 활용한다.
오브젝트 구조를 만들어놓으면 테이블의 관계를 그대로 객체에서도 써먹을 수 있다.
1 | Set<Order> orders = member.orders(); |
데이터 중심 방식에서는 하나의 맵에 뭉뚱그려서 가져왔었고, 이를 위해서 맵을 파헤치는 작업이 필요하고, 그에따른 오류가 있기마련인데, 오브젝트 중심방식에서는 관계를 그대로 유지가 가능하다.
도메인 오브젝트 중심의 단점은 사용하지 않는 필드까지 가져와 매핑을 시킨다는 것이다. 연관된 객체가 있을경우에 이 단점이 더 커보이는데, 연관된 객체가 null이면 예상치 못하게 NullPointerException을 만나게 될 수 있다. 하지만, lazy loading 기법을 활용하면 최소한의 정보만 DB에서 읽어오고, 연관된 객체는 그때 그때 다이나믹하게 디비에서 읽어 올 수 있다.
이러한 도메인 오브젝트 중심의 개발을 돕는 것이 ORM (Object Relational Mapping) 기술이고, 자바의 표준은 Java Persistence API -> JPA 라고 볼 수 있는데 이것에 대한 상세한 얘기와 Mybatis 개발방법 비교는 다음에 이어 하도록 하자.