ORM(Object Relational Mapping)

ORM(Object Relational Mapping) 에 대해 작성한다.

ORM이란 객체와 관계형 데이터베이스의 데이터를 자동으로 연결해주는 것을 말한다.

오브젝트<--ORM매핑-->Relational Database

 

객체지향 프로그래밍은 클래스를 사용하고 관계형 데이터베이스는 테이블을 사용하기 때문에 객체 모델과 관계형 모델 간에 불일치와 이질성이 존재한다. ORM을 이용하여 객체의 형태로 데이터베이스에 SQL을 자동으로 생성하여 객체를 삽입하고 수정 등이 가능하다. ORM에서 말하는 객체의 의미는 OOP의 객체를 의미한다. 관계는 관계형 데이터베이스를 의미한다.

객체를 통해 간접적으로 데이터베이스 데이터를 다룬다. Persistant API라고도 할 수 있다.(JPA, Hibernate)

 

ORM을 사용하면 객체 지향적인 코드로 직관적이고 비즈니스 로직에 더 집중하여 개발할 수 있다.  각종 객체에 대한 코드를 별도로 작성하여 코드의 가독성을 올려주며 절차적이고 순차적인 접근이 아닌 객체지향적인 접근으로 생산성을 증대할 수 있다.

 

재사용성 및 유지보수 편리성이 증가한다. ORM은 독립적으로 작성되어 있어 해당 객체들을 재활용 할 수 있다. 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리하다. 매핑정보가 명확하기 때문에 ERD를 보는 것에 대한 의존도를 낮출 수 있다.

 

DBMS에 대한 종속성이 줄어든다. 대부분 ORM 솔루션은 DB에 종속적이지 않다. 프로그래머는 객체에 집중함으로 DBMS 교체 등의 거대한 이슈에도 비교적 적은 리스크와 시간으로 대응할 수 있다. 

 

하지만, ORM만으로 서비스를 구현하기에는 어렵다. 사용하기 편하지만 설계에 매우 신중해야 하며 프로젝트의 복잡성이 커질 경우 난이도가 올라가게된다. 잘못 구현된 경우 속도 저하 및 일관성이 무너지는 문제가 발생할 수 있다. 

프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어렵다. 프로시저를 객체화 해야하기 때문에 생산성 저하나 리스크가 많이 발생할 수 있다.

 

ORM을 적절하게 사용하기 위해선 타겟 데이터베이스를 이해해야 한다. ORM 적용 시 SQL 및 데이터베이스의 락킹 모델을 무시하면 안된다. O-R 매핑은 작업을 쉽게 해주는 툴이지만 구현되는 환경에 대한 이해를 불필요하게 만들어주는 툴은 아니다.

 

필요한 경우 SQL을 사용하는 것을 두려워하지 말아야 한다. 작업 시 경우에 따라 ORM 이 아니라 SQL 문을 직접 작성해야 하는 경우가 있다.

 

O-R 매핑 제품을 선택하기 전에 충분히 검토해야 한다. 모든 ORM 제품들이 동일한 수준의 기능을 제공하는 것이 아니기 때문에 요구사항을 반영하는 환경을 구축하고 2~3가지 제품을 비교 테스트 해봐야 한다. 이 과정을 통해 ORM이 성능 기준을 만족하는지 검증할 수 있다. 엔터프라이즈 개발 과정의 다른 요소들과 마찬가지로 프로젝트 라이프사이클의 초기 단계에서 성능과 관련된 리스크를 최소화하는 것이 중요하다. 

 

ORM이 적절하게 사용될 수 있는 상황을 이해해야 한다. ORM은 엔티티를 개별적으로 업데이트하고 간헐적으로 셋 기반 작업을 수행하는 OLTP 애플리케이션에 특히 적합하다.

 

ORM이 적절하지 않은 경우에 대해서도 이해해야 한다. 많은 수의 레코드에 대해 잦은 빈도로 업데이트를 수행하는 애플리케이션의 경우 ORM이 적절하지 않다. OLAP 애플리케이션에서는 데이터를 본래의 엔티티 상태로 사용하기 어렵다. 데이터의 인출 및 업데이트를 위해 핸드코딩으로 작성된 SQL 및 저장 프로시저를 이용하는 데이터베이스 환경의 경우 JDBC 기반의 접근 방법이 최선의 선택이 될 수 있다. iBATIS SQL Maps 역시 이러한 환경에서 빛을 발한다.

 

하지만 몇몇 ORM 제품은 기존 스키마 및 저장 프로시저와 효과적으로 연동될 수 있기에 이러한 환경에서도 ORM의 사용을 고려할 가치가 있다. 순수 SQL 기반 접근 방법을 적용하는 것이 적절한 애플리케이션에도 ORM이 적절하지 않다. 비즈니스 로직이 대부분이 데이터베이스에 이미 구현되어 있거나 데이터베이스 무결성 제약이 적용되어 있는 경우 등이 그 예이다. 이러한 애플리케이션에서는 오브젝트 또는 ORM의 활용 여지가 매우 적어 데이터베이스 테이블을 도메인 오브젝트로 모델링하여 기대할 수 있는 효과가 거의 없기 때문이다.