ORM(Object-Relational
Mappings)라는
건 과연 무엇일까?
근래
많이 보고 듣는 단어이고 ORM Framework이나
Tool이니 하면서 Hibernate나 iBatis,
Toplink등등의 이름들도 많이 듣게 된다. 과연 이
ORM이라는 것이 무엇이길래 왜 이렇게 많은 사람들의 입에 오르내리는 것일까?
ORM이라는
것을 단순하게 표현해보자면 객체와 관계와의 설정? 정도일까?
그럼 여기서 말하는 객체라는 것은 우리가 흔히 말하는 OOP(Object-Oriented
Programming)의 그 객체를 이야기 하는 것 이라면, 과연 관계라는 것이 의미하는
것은 무엇일까? 뭐 지극히 기초적인 이야기지만 우리(개발자)가 흔히 사용하고 있는 관계형 데이터베이스를
의미한다.
그렇다면
도대체 무엇이 문제여서 객체와 관계형 데이터베이스 간의 매핑을 지원해주는
Framework이나 Tool들이 나오는 것일까?
이미 우리는 OOP를 하면서 객체와 관계형 데이터베이스를 모두 잘 사용하고 있지
않은가? 그런데도 굳이 이런 새로운 개념들이 나오게 되는 이유는 흔히 말해서 Back to basics 라고 볼 수 있겠다. 즉, 보다 OOP다운 프로그래밍을 하자는 데 에서부터 출발한
것이다.
그럼
과연 무엇이 문제였던 것일까? 생각해보면 당연하게 문제가 있을 수 밖에 없다고 생각되어진다. 스스로 한번 생각해보자. 우리가 어떤 어플리케이션을 만든다고 할
때 관련된 정보들은 객체에 담고 있게 된다. 많이들 예를 드는 주소록을 만든다고 생각을
해보자. 일단은 주소록의 주체가 될 사람이라는 객체가 있다고 가정해보면 주민등록번호, 이름, 키, 몸무게
등등이 저장될 것이다. 그리고 주소라던지 전화번호등이 저장 될 다른 객체(여기서는 주소만을 가정해보고 주소라는 객체라고 가정한다.)도 있게
될 것이다. 그럼 이것을 영구적으로 저장하기 위해서 파일이나 데이터베이스에 입력을 한다고
하면, 객체와 객체들의 관계를 데이터베이스의 테이블에 저장을 하게 된다는 말과 동일하게 된다. 즉 table들에 객체가 가지고 있던 정보를 입력하고 이 table들을 join과 같은 sql
query문을 통해서 관계를 설정해주게 된다. 여기서 문제는 이 table들과 객체간의 이질성이 발생을 한다는 것이다.
보통
ORM Framework들은 이러한 이질성을 해결하기 위해서 객체와 table간의 관계를
설정하여 자동으로 처리를 해준다는 것이다. 개인적으로 많은 ORM
Framework를 접해본 것이 아니라서 어떤 방법들이 사용되는지는 잘 모르겠지만, 예를
들어서 눈으로 확인해보자면 다음과 같은 Person이라는 객체가 있다고 가정한다.
public
class
Person {
private
String name;
private
String height;
private
String weight;
private
String ssn;
//
implement getter & setter methods
}
iBatis의
경우에는 다음과 같이 mapping file내에서 해당
query의 결과를 받을 객체를 지정해 줄 수 있다.
<select
id=“getPerson”
resultClass=“net.agilejava.person.domain.Person”>
SELECT name, height, weight, ssn FROM USER WHERE name =
#name#;
</select>
즉, 이 getPerson라고 정의된
query의 결과는 net.agilejava.person.domain의 Person객체에 자동으로 mapping 되는 것이다. Hibernate의 경우에는 mapping 파일에서 다음과 같이
표현을 해준다.
<hibernate-mapping>
<class
name=“net.agilejava.person.domain.Person”
table=person”>
<id
name=“name”
column=“name”
/>
<property
name=“height”
column=“height”
/>
<property
name=“weight”
column=“weight”
/>
<property
name=“ssn”
column=“ssn”
/>
</class>
</hibernate-mapping>
위 두개의 Framework의 예시를 보면 알 수 있듯이 setter 메소드가
있다면 객체에 결과를 set하는 작업들이 따로 필요한 것이 아니라 자동으로 setting 되는 것이다. 물론 여기에 추가적으로 1:m 이나 m:1 등의 관계들이 형성되면 추가적인 작업이 필요하긴
하지만 어쨌든 일단 눈에 보이는 간단한 부분은 처리가 되는 것을 볼 수 있다. 물론 반대의 경우에도
객체를 던져주면 ORM Framework에서 알아서
get을 해와서 해당하는 column에 넣어주게 된다.
어떻게 보면 더 복잡해 보일 수 도 있는
ORM이지만 막상 사용해보면 그 편리함에 몸을 떨게 된다. 단순하게 get/set만 해주는게 목적이 아니라 객체지향적인 시스템을 위해서 관계형데이터베이스의 설계부터 변화를
주고, 설계된 데이터베이스와 객체와의 관계에 대한 설정 등을 포함하여 보다 객체지향적인 시스템의
완성을 위한 도구라고 말할 수 있겠다. 물론 ORM이라는
것이 흔히 말하는 silver bullet은 절.대. 아니다. 이 녀석이
쓰여서 이득을 볼 수 있는 부분이 존재할 것이며, 쓰지 않아서 이득을 볼 부분이 존재 할
것이다. 많은 사람들이 ORM에 대하여 우려하고 있는
부분은 객체지향적으로 설계되지 않은 데이터베이스에서의 사용에 따른 폐혜라고 생각한다. 이미
데이터베이스 중심적인 사고를 통하여 만들어 놓은 데이터베이스에 ORM을 도입을 해서도 분명 이점이
있긴하겠지만, 그에 비해서 개발자들의 학습곡선 이라던지,
기존에 존재하는 코드나 시스템들과의 연계 또는 유지보수적인 측면, 그리고 성능 등에서
생각해보면 부정적으로 볼 수 밖에 없다. 즉, 전체적인
시스템의 분석,설계 단계에서부터 객체와 데이터베이스를 따로 생각하는 것이 아니라 하나의 덩어리로
인지하고 양쪽 모두를 고려한 설계를 해나갈 수 있을 때, ORM은 보다 좋은 모습을 보여주고 각광을
받을 수 있을 것이다.