‘sql문이 획기적으로 줄어들며, 보다 객체지향적인 설계 및 구현이 가능하다!’
학교 Database programming 수업에 ORM platform 중 하나인 iBatis를 고려할 때 한 사이트에서 읽었던 구문이다. 이 글을 읽고 iBatis에 대한 자료를 찾아다닐때만 해도 내가 모르는 무언가에 대한 호기심에 눈이 반짝이던 때였다.
ORM platform의 사용이 필수요건은 아니었지만, 다른 조에 비해 무언가 나은 것을 보여주어야한다는 강박관념 또한 우리를 iBatis를 사용하게 만들었다. 그리고, 그것을 쓰면 sql문이 줄어든다는 걸 보니, 구현 속도도 분명 빨라질 것이라고 생각했다.
하지만, 학교 한학기 프로젝트 정도 규모에 사용하기에는 너무 초기 리소스가 많이 투입되는 문제가 있었다. 그렇지 않아도 Java와 JSP 등의 개발 경험이 전무한 우리(겨우 2명)이 Database, Java application, JSP Web site, 비지니스 로직 등을 모두 설계해야하는 상황에 있어 iBatis 설정과 사용법에 대한 학습은 한정된 프로젝트 시간 중 지나치게 많은 부분을 차지해버렸다.
익숙치 개발환경과 개발툴도 문제였다. 이클립스는 분명 좋은 개발툴이었지만 (개인적으로 느끼기에는) C/C++ 계열의 VS보다 안정성, 신뢰성에서는 좀 떨어지는 느낌이었다. GUI 부분을 개발할 때 이클립스는 수없이 많은 Unknown error를 뱉어내었고 이때문에 소스를 날려먹은 적이 한두번이 아니었다. 게다가 iBatis에서 Mapping 및 Setting용 XML 파일들은 중간에 고장이날 경우 어디서 고장이났는지 디버깅 메시지조차 친절하지 않았기 때문에 더욱 고생하였다. (XML 문서 중 하나가 고장나면 main을 실행할 수 없다는 에러메시지 하나만 뱉어낼 때도 있다. 이런 경우에는 정말 버그를 잡기 힘들었다.)
결국, 기말 프로젝트 발표시에는 iBatis를 사용한 비지니스 로직(Database-entitiy-control objects 등)의 구축은 어느정도 마칠 수 있었다. 하지만 정작 교수님 및 다른 학생들에게 보여지는 Application이나 Webpage는 그저 한 두개 정도의 기능 제공에 그칠 뿐이었고, 그나마 예외처리도 거의 이루어지지 않은, 매우 불안정한 모습을 보여줄 수밖에 없었다.
어찌되었건, 결과적으로 우리는 iBatis를 사용한 DB programming을 경험해봤다. 확실히 ORM을 사용하였을 경우 그렇지 않을 경우에 비해 데이터베이스-응용 프로그램 간의 유연성은 획기적으로 개선될 것이라고 생각된다. 하지만 그 이면에는 아직 몇몇 문제점 (단적인 예로 객체로 출력시에는 다단계 식으로 ResultMap을 사용하여 객체를 뽑아낼 수 있지만 그 반대로 다단계 식의 객체를 한번에 넣는 것은 불가)이 있는 것도 사실이고, 약간은 명확하지 않은 기능들도 존재하는 것 같다. 하지만 그 유연성 만큼은 좋다고 생각된다.
다음에도 Database와의 연동이 포함된 project를 진행할 때 iBatis를 사용할 것인가? 라는 질문에는 일단은 Yes이다.(물론 프로젝트 사이즈에 따라 결정하겠지만), 많은 어려움에도 불구하고 iBatis는 여전히 매력적이다.
ps. 경☆명박산성 건립기념☆축 다이내믹 코리아
'사는 이야기' 카테고리의 다른 글
| iBatis 삽질기 (1) | 2008/06/11 |
|---|---|
| 블로그 스킨(테마)에 대한 생각. (0) | 2008/04/05 |
| 설문 및 테스트 (2) | 2008/03/29 |
| 다음, 이러면 기사통계가 있을 필요가 없잖아! (0) | 2008/03/15 |
| 갑자기 디제잉을 배우고싶다-_-... (2) | 2008/02/25 |
| 통장비닐을 이용한 화이트밸런스 필터 자작 (4) | 2008/02/21 |