[Spring Framework] DB 액세스 프레임워크의 종류

 

 

DB 액세스 프레임워크로 흔히 알려진 것은 ORM(O/R 매핑 프레임워크)이다. ORM은 XML 드응로 기술된 매핑 파일로, 오브젝트와 테이블을 매핑한다. 매핑 파일 작성은 손이 많이 가지만 개발자가 SQL 문을 작성하지 않아도 된다는 특징이 있다.

ORM의 대표적인 프레임워크가 하이버네이트이다. 반면 직접 SQL문 사용을 전제로 한 DB 액세스 프레임워크도 있다. 스프링에 포함된 스프링 JDBC나 MyBatis가 여기에 해당한다.

 

데이터 액세스 층의 설계 지침

설계를 생각하기 전에 데이터 액세스 층의 구현을 생각해보자.
데이터 액세스 층의 구현은 O/R 매핑인지 R/O 매핑인지에 따라 달라진다. O/R 매핑은 ORM이라고 일컫는 하이버네이트 등을 이용한다. R/O 매핑으로도 테이블 구조가 복잡하면 스프링 JDBC처럼 직접 SQL을 이용하는 방법도 생각해볼 수 있따. 하이버네이트 같은 프레임워크를 이용하면 다음과 같은 '설계 시 고려해야 하는 내용'이 포함되어 있어서 이를 별도로 설계하지 않아도 된다.

커넥션 풀링을 이용한다.

커넥션(conenction)을 이용할 때마다 생성하고 해제하는 것은 효율적이지 않다. 일반적인 DB 액세스 프레임워크에서는 커넥션 풀링을 이용할 수 있다.

 

RDB(제품)가 바뀌어도 구현에 영향을 미치지 않게 한다.

일반적인 DB 액세스 프레임워크에서는 이용할 RDB, 예를 들어 HSQLDB와 Oracle 등을 설정 파일에서 지정하므로 RDB가 바뀌어도 구현에 영향을 미치지 않는다.

이용하는 RDB에 의존적인 SQL 문을 기술하지 않는다.

ORM에서는 설정 파일로 지정한 RDB에 의해 출력되는 SQL 문이 자동으로 변환된다. 직접 SQL문을 기술하는 방식의 DB 엑세스 프레임워크에서는 RDB에 의존하는 SQL문을 기술하지 않도록 주의해야 한다. 특히 주의할 것은 자동 증가 프라이머리 키 생성 방법과 현재 날짜 등을 구하는 함수 등이 RDB에 의존하는 기능이다.

지금까지 설명으로 알 수 있듯이 DB 액세스 프레임워크가 포함되므로 데이터 액세스 층에서는 설계할 곳이 거의 없다. 데이터 액세스 층의 인터페이스만 설계하면 된다. 즉, 테이블과 도메인의 관계, 다시 말해 O/R 매핑 부분만 설계한다. 테이블과 도메인 설계가 끝나면 그 시스템의 특징과 필요한 성능을 얻을 수 있는 DB 액세스 프레임워크를 선택하면 된다.

비즈니스 로직 층과 데이터 액세스 층의 분리

하지만 이것만으로는 여전히 문제가 남는다. 우리가 목표로 하는 것은 비즈니스 로직 층과 데이터 액세스 층의 상호 의존을 없앤 오목형 레이어다.

일반적인 설계로는 트랜잭션 관리를 위해 비즈니스 로직 층에서 java.sql.Connection(하이버네이트이면 세션)을 취득해서 데이터 액세스 층에 전달하는 인터페이스가 된다. 이래서는 아무리 인터페이스 기반으로 하더라도 데이터 액세스 층이 비즈니스 로직 층에 의존하게 된다. 인터페이스로부터 커넥션을 분리하는 방법으로는 ThreadLocal을 이용한 패턴 사용 등을 생각할 수 있지만, 이는 꽤 귀찮은 방법이다. 이 책에서는 나중에 스프링을 사용해 간단히 구현해보자.



Column3 파티션 혹은 인프라 층

스프링을 레이어에 맞추려고 하면 상당히 어렵다.
프레젠테이션 층은 스프링 MVC고 데이터 액세스 층은 스프링 JDBC로 할 수 있지만, 코어인 DIxAOP와 스프링 시큐리티 같은 것은 레이어에 걸쳐있다. 3층(프레젠테이션 층/ 비즈니스 로직 층/ 데이터 액세스 층)에 넣을 때도 있지만 이 포스팅에서는 스프링은 레이어에서 독립돼 있고, 레이어는 개발자가 작성하는 것을 넣는 것으로 생각한다.

그래도 레이어를 그림으로 표현할 필요가 있다면 그 때는 레이어에 독립된 파티션, 혹은 레이어로 인프라 층을 만들어서 거기에 스프링을 넣는다고 생각할 수 있다.