[06] Mybatis와 스프링 연동

1. Mybatis란?

흔히 'SQL 매핑 프레임워크'로 분류되는데, 개발자들은 JDBC 코드의 복잡하고 지루한 작업을 피하는 용도로 많이 사용한다. 

 

• 기능이자 장점

- 자동으로 Connection close()< 가능

- mybatis 내부적으로 PreparedStatement 처리

- #{prop}과 같이 속성을 지정하면 내부적으로 자동 처리

- 리턴 타입을 지정하는 경우 자동으로 객체 생성 및 ResultSet 처리

 

스프링 프레임워크의 특징 중 하나는 다른 프레임워크들을 배척하는 대신에 연동을 쉽게하는 추가적인 라이브러리가 많다는 것! mybatis 역시 mybatis-spring이라는 라이브러리를 통해 쉽게 연동작업을 처리할 수 있다!

앞으로 예제에서 사용하게 될 구조

 

2. Mybitis 관련 라이브러리 추가하기

2-1. pom.xml 파일에 아래와 같은 소스코드를 추가한다.

- spring-jdbc/spring-tx : 스프링에서 데이터베이스 처리와 트랜잭션 처리(해당 라이브러리들은 Mybatis와 무관하게 보이지만 추가하지 않은 경우에 에러가 발생하므로 주의!)

 

(#{org.springframework-version} 이라 적힌 부분은 자신의 스프링 버전에 맞게 작성해 주어야함! 나는 5.0.7.RELEASE)

 

2-2. SQLSessionFactory

Mybatis에서 가장 핵심적인 객체는 SQLSession이라는 존재와 SQLSessionFactory다!

SQLSessionFactory의 이름에서 보듯이 내부적으로 SQLSession이라는 것을 만들어 내는 존재인데, 개발에서는 SQLSession을 통해서 Connection을 생성하거나 원하는 SQL을 전달하고, 결과를 리턴 받는 구조로 작성하게 된다.

 

- root-context.xml에서 아래와 같은 코드로 작성한다.

 

3. 스프링과의 연동 처리

SQLSessionFactory를 이용해서 코드를 작성해도 직접 Connection을 얻어서 JDBC 코딩이 가능하지만, 좀 더 편하게 작업하기 위해서는 SQL을 어떻게 처리할 것인지를 별도의 설정을 분리해 주고, 자동으로 처리되는 방식을 이용하는 것이 좋다. 이를 위해서는 Mybatis의 Mapper라는 존재를 작성해 주어야한다!

 

- Mapper란?

쉽게 말해서 SQL과 그에 대한 처리를 지정하는 역할을 한다. Mybatis-spring을 이용하는 경우에는 Mapper를 XML과 인터페이스 + 어노테이션의 형태로 작성할 수 있다.

 

3-1. Mapper 인터페이스

Mapper를 작성하는 일은 XML을 이용할 수도 있지만, 최소한의 코드를 작성하는 Mapper 인터페이스를 사용해보겠다.

3-1-1. org.zerock.mapper라는 패키지를 만들고 TimeMapper라는 인터페이스를 추가한다.

package org.zerock.mapper;
 
import org.apache.ibatis.annotations.Select;
 
public interface TimeMapper {
    @Select("SELECT sysdate FROM dual")
    public String getTime();
}
 

3-1-3. root-context.xml 코드 추가

- <mybatis-spring:scan> 태그의 base-package 속성은 지정된 패키지의 모든 MyBatis 관련 어노테이션을 찾아서 처리한다. Mapper를 설정하는 작업은 각각의 XML이나 Mapper 인터페이스를 설정할 수도 있지만, 매번 너무 번잡하기 때문에 예제는 자동으로 org.zerock.mapper 패키지를 인식하는 방식으로 작성하는 것이 가장 편리하다.

 

3-2. Mapper 테스트

Mybatis-Spring은 Mapper 인터페이스를 이용해서 실제 SQL 처리가 되는 클래스를 자동으로 생성한다. 따라서 개발자들은 인터페이스와 SQL만을 작성하는 방식으로도 모든 JDBC 처리를 끝낼 수 있다.

 

3-2-1. src/test/java 밑에 rog.zerock.persistence.TimeMapperTests 라는 클래스를 생성해서 처리한다.

소스코드 + 결과화면

 

3-3. XML 매퍼와 같이 쓰기

Mybatis를 이용해서 SQL을 처리할 때 어노테이션을 이용하는 방식이 압도적으로 편리하기는 하지만, SQL이 복잡하거나 길어지는 경우에는 어노테이션 보다는 XML을 이용하는 방식을 더 선호하게 된다!

다행이도 Mybatis-Spring의 경우 Mapper 인터페이스와 XML을 동시에 이용할 수 있다.

 

XML을 작성해서 사용할 때에는 XML 파일의 위치와 XML 파일에 지정하는 namespace속성이 중요한데, XML 파일 위치의 경우 Mapper 인터페이스가 있는 곳에 같이 작성하거나 다음 그림처럼 src/main/resources 구조에 XML을 저장할 폴더를 생성할 수 있다. XML파일을 만들 때 이름에 대한 규칙은 없지만, 가능하다면 Mapper 인터페이스와 같은 이름을 이용하는것이 가독성을 높여준다.

 

3-3-1. src/main/resources 폴더 내 다음 그림과 같이 org 폴더와 하위에 zerock 폴더, mapper 폴더를 작성한다. (폴더 생성시 반드시 한 번에 하나씩 폴더를 생성한다. 만일 한번에 폴더를 만들면 제대로 인식이 되지 않는 문제가 발생하므로 주의한다!)

 

3-3-2. 생성된 폴더에 TimeMapper.xml 파일을 생성한다.

 * XML 파일에는 MyBatis의 XML 매퍼에서 이용하는 태그에 대한 설정이 필요하다.

이에 대한 자세한 정보는 http://www.mybatis.org/mybatis-3/ko/sqlmap-xml.html 을 통해서 확인할 수 있다.

 

3-3-3. Mapper 인터페이스와 XML을 같이 이용해 보기 위해서 기존의 TimeMapper 인터페이스에 추가적인 메서드를 선언한다.

앞서 선언했던 getTime()과는 다르게 어노테이션도 없고 SQL문도 없는 것을 볼 수 있다. 

 

3-3-4. TimeMaper.xml 코드

 - XML 매퍼를 이용할 때 신경 써야 하는 부분은 <mapper> 태그의 namespace 속성값이다. MyBatis는 Mapper 인터페이스와 XML을 인터페이스의 이름과 namespace 속성값을 가지고 판단한다. 위와 같이 org.zerock.mapper.TimeMapper 인터페이스가 존재하고, XML의 <mapper namespace="org.zerock.mapper.TimeMapper">와 같이 동일한 이름이 존재하면, 이를 병합해서 처리한다. 따라서 위의 경우 메서드 선언은 인터페이스에 존재하고 SQL에 대한 처리는 XML을 이용하는 방식이라고 볼 수 있다.

 - <select> 태그의 id 속성 값은 메서드의 이름과 동일하게 맞춰야 한다. <select> 태그의 경우 resultType 속성을 가지는데 이 값은 인터페이스에 선언된 메서드의 리턴 타입과 동일하게 작성한다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper
    PUBLIC "-//mybatis.rog//DTD Mapper 3.0//EN"
    "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
 
<mapper namespace="org.zerock.mapper.TimeMapper">
    <select id="getTime2" resultType="string">
    SELECT sysdate FROM dual
    </select>
 
</mapper>

    @Test
    public void testGetTime2() {
        log.info("getTime2");
        log.info(timeMapper.getTime2());
    }

결과 화면은 getTime과 동일

 

4. log4jdbc-log4j2 설정하기

Mybatis는 내부적으로 JDBC의 PreparedStatement를 이용해서 SQL을 처리한다. 따라서 SQL에 전달되는 파라미터는 JDBC에서와 같이 '?'로 치환되어서 처리된다. 복잡한 SQL의 경우 '?'로 나오는 값이 제대로 되었는지 확인하기가 쉽지 않고 실행된 SQL의 내용을 정확히 확인하기는 어렵다. 이런 문제를 해결하기 위해서 SQL을 변환해서 PreparedStatement에 사용된 '?'가 어떤 값으로 처리되었는지 확인하는 기능을 추가하도록 한다. SQL 로그를 제대로 보기 위해서는 log4jdbc-log4j2 라이브러리를 사용해야 한다.

 

4-1. pom.xml에 라이브러리를 설정한다.

추가한 후에는 1) 로그 설정 파일을 추가하는 작업과 2) JDBC의 연결정보를 수정해야 한다.

 

4-2. src/main/resources 밑에 log4jdbc.log4j2.properties 파일을 추가한다.

4-3. log4jdbc를 이용하는 경우는 JDBC 드라이버와 URL 정보를 수정해야한다. 

 - root-context.xml 일부를 수정한다.

 - JDBC 드라이버의 클래스를 'net.sf.log4jdbc.sql.jdbcapi.DriverSpy'로 수정하는 작업과 JDBC 연결 URL 부분에서 중간에 'log4jdbc' 문자열이 추가된다. 이 두 설정이 제대로 되어 있지 않으면 데이터베이스의 로그가 정상적으로 기록되지 않는다.

(위에 log3jdbc:oracle:~ 이라고 된 오타를 log4jdbc:oracle~ 이라고 바꾸자~)

 

4-4. 설정 후 테스트 코드를 실행해보자.

4-5. 로그의 레벨 설정

테스트 코드를 실행하면 상당히 많은 양의 로그가 출력되기 때문에 처음 개발할 때는 좋지만 시간이 지나면서 불편하다고 느낄 수 있다. 이런 상황에서는 로그의 레벨을 이용해서 조금 수정해줄 필요가 있따.

 

테스트 코드가 실행될 때의 로그와 관련된 설정은 src/test/resources 밑에 log4j.xml을 이용한다.

 - 기존 설정의 로그는 info 레벨이기 때문에 warn과 같이 좀 더 높은 레벨의 로그만 기록하게 수정하면 테스트 코드를 실행할 때 이전에 비해 로그의 양이 줄어드는 것을 확인할 수 있다.

로그 레벨에 대한 자세한 설명은 http://logging.apache.org/log4j/2.x/manual/customloglevels.html 참고

 

4-5-1. 결과화면

 - 에러가 떴다... 왜일까?...

책과 다르게 </log4j:configuration> 태그 닫기전으로 코드를 옮기니 정상적으로 뜨긴 뜸...