iBatis 그리고 JDBC 어떻게 다른가?

iBatis가 좋다는 말은 많이 한다. 

코드도 줄어든다고 한다.

재사용성도 높아진단다.

그런데 대강 이렇다고는 하는데 뭐가 달라지는 건지 진짜 좋아지는 건가 하는 생각을 했었다.

그래서 직관적인 코드를 통해서 변화와 좋은 점을 한번 알아보려고 한다.

위를 보자 왼쪽의 기존의 것을 SQL을 사용하여 매핑해서 오른쪽이 나왔다 

좀 나아 보이는가? 단지 이름을 ALIAS한 것뿐 이다 –ㅅ-.. 그래도 좀 나아 보이지 않는가? 

여기에서부터 시작해보자

SQL 매핑하기

모든 SQL 구문은 입력과 출력으로 이루어져 있다. 입력은 대게 SQL구문의 WHERE절에서 볼 수 있는 파라미터이다. 

출력은 SELECT 절에서 볼 수 있는 칼럼이다.

아래의 그림은 이러한 생각을 보여준다

 

이 접근법의 장점은 개발자가 SQL 구문을 매우 유연하게 다룰 수 있다는 점이다. 

개발자는 DB 테이블을 변경하지 않고도 데이터를 객체 모델과 일치하도록 조절할 수 있게 된다. 

게다가 개발자가 DB의 여러 테이블, 내장 함수, 저장 프로시저로부터 생성되는 결과 값을 가져 오는 것이 실직적으로 가능해진다.

즉, 개발자가 SQL의 능력을 모두 다 사용할 수 있게 되는 것이다.

 

iBtis는 간단한 XML 서술 파일을 사용하여 SQL구문의 입력과 출력을 매핑한다.

다음은 이를 간단하게 보여주는 것이다.

 

			SELECT
				ADR_ID		 	as identifier,
				ADR_DESCRIPTION	as description,
				ADR_STREET		as street,
				ADR_CITY		as city,
				ADR_PROVINCE	as province,
				ADR_POSTAL_CODE	as postalCode,
			FROM ADDRESS			
			WHERE ID = #id#

 

여기서 주소(address)데이터를 반환하는 SQL SELECT 구문을 볼 수 있다. <SELECT> 요소의 WHERE절에서 #id#로 표시된 

Integer 형 값이 파라미터로 설정됐다. 이 쿼리의 결과가 Address 클래스의 객체 인스턴스로 매핑됨을 알수 있다.

 

이를 자바 코드로 한번 표현해보자.

Address address = (Address) sqlMap.queryForObject("getAddress", new Integer(5));

물론 다른 상세한 옵션이 있지만 나중에 보기로 하고 직관적인 변화를 보기로 하자

무엇보다도 iBatis는 JDBC의 코드 작성을 대신하는 것이다(JAVA기준). 

JDBC의 API는 매우 강력하지만 장황하고 반복적인 성향이 있다.

아래는 JDBC의 예제이다.

public Employee getEmployee (int id) {

		Employee employee = null;

				String slq = "SELECT * FROM EMPLOYEE WHERE EMPLYEE_NUMBER = ?";

				Connection conn = null;
				PreparedStatement pstmt = null;
				ResultSet rs = null;

				  try {
					conn = dateSource.getConnection();
					pstmt = conn.prepareCall( sql );
					rs = pstmt.executeQuery();

						while( rs.next() ) {
							employee = new Employee();
							employee.setId( rs.getInt( "ID" ) );
							employee.setEmployeeNumber( rs.getInt( "EMPLOYEE_NUMBER" ) );
							employee.setFirstName( rs.getString( "FIRST_NAME" ) );
							employee.setLastName( rs.getString( "LAST_NAME" ) );
							employee.setTitle( rs.getString( "TITLE" ) );
						}
				} finally {

					try {

					if( rs != null ) rs.close();

					} finally {

						try {
							if ( pstmt != null ) pstmt.close();
						} finally {
							if ( conn != null ) conn.close();
						}
					}
				}
			return employee;
		}

코드의 모든 줄이 꼭 필요한 것이라서 더 이상 줄이기에는 힘들지만,  

JDBC 의 API에 의해 야기되는 불편함을 쉽게 알아 볼 수 있다.

쉽게 접근해보자면 유틸리티성의 메소드를 한번 보자

PreparedStatement 와  ResultSet과 같은 자원에 대해 close() 메소드를 호출해 주는것이다.

물론 iBatis도 거의 비슷하게 작동할 것이다.

즉 DB로부터 커넥션을 얻고, 파라미터를 설정하고, 쿼리구문을 실행하고 결과를 가져오고 나서 모든 자원을 닫는다.  

즉, JDBCD와 같은 순서를 따를꺼라는 말이다. 

하지만 우리가 작성해야 하는 코드의 양은 눈에 띄게 줄어든다.

다음은 바로 위의 JDBC와 완전히 같은 동작을 하기 위한 구문을 iBatis형식으로 작성한 것이다.

  

			SELECT
 				ID					as id,
				EMPLOYEE_NUMBER		as employeeNumber,
				FIRST_NAME			as firstName,
				LAST_NAME			as lastName,
				TITLE				as title
			FROM EMPLOYEE
			WHERE EMPLOYEE_NUMBER = #empNum#

이는 위에서 봤던 단 한줄의 java코드만 있으면 된다.

 

Address address = (Address) sqlMap.queryForObject("getAddress", new Integer(5));

 

다른 것은 필요 없다. 이 코드는 구문을 실행하고 파라미터를 셋팅하며 실제 자바 객체로 결과를 가져온다. 

SQL은 xml파일을 통해 적절히 캡슐화 되고  코드의 외부로 분리된다. 

iBatis는 보이지 않는 곳에서 모든 자원을 관리하면서 위의 JDBC 코드와 동일한 효과를 낸다.

 

끝난 것 아닌가?

비교의 여지가 없다. iBatis는 간결하고 읽기 쉽고, 따라서 유지 보수 하는 것도 더 쉽다.

이로서 iBatis가 쓸만하다는 느낌이 왔을것이다.

하지만 궂이 사용을 해야하나? 라는 의문이 들겠지만… 

이는 다음 글을 통해서 파해쳐 보자