ibatis의 탄생 철학

출처: http://blog.naver.com/2000yujin/130154067545

 

: iBATIS 역사

: iBATIS 이해

: 데이터베이스 종류

 

iBATIS는 관계형 데이터베이스와 SQL의 가치를 인정하고 산업 전반에 걸친 SQL에 대한 투자를 그대로 이어가겠다는 생각을 기반으로 하고 있다. iBATIS는 SQL로 더 쉽게 작업할 수 있도록 SQL 사용을 기꺼이 받아들였고, 현대적인 객체 지향 소프트웨어와의 통합을 더 쉽게 만들어 주는 퍼시스턴스 계층(persistence layer) 프레임워크로 자리매김 했다.

 

1.1 복합적인 솔루션 : 최고 중의 최고들로 구성하기

 

현대 세계에서는 복합적인 솔루션을 어디서든 찾아볼 수 있다. 겉으로 보기엔 서로 반대되는 두 생각을 받아들여 중간에서 그것들을 합치면 간극을 메워주는 아주 효율적인 방법이 만들어질 수 있음이 증명되었다.

 

복합적인 솔루션은 IT 산업에 있어서도 그 효과를 증명했다. iBATIS가 소프트웨어 애플리케이션의 퍼시스턴스 계층을 위한 바로 그러한 복합적인 솔루션이다.

 

1.1.1 iBATIS의 기원 답사

 

iBATIS는 관계형 데이터베이스에 접근하는 가장 잘 알려진 방법들로부터 가장 좋은 특징과 아이디어들을 차용했고, 그것들로부터 시너지를 이끌어 낸다.

 

<그림> iBATIS가 개발 프로세스를 단순화하기 위해 끌어다 모은 몇몇 개념들

 

SQL

 

SQL은 단순하고 비절차적(non-procedural)인 언어로 데이터베이스와 함께 작동하며 사실은 두 가지 언어를 하나로 합친 것이다.

 

첫째는 데이터 정의 언어(Data Definition Language, DDL)로 데이터베이스의 구조와 설계를 정의하는데 사용한다.

 

SQL의 두 번째 부분은 데이터 조작 언어(Data Manipulation language, DML)이다. DML은 데이터를 직접 조가하기 위해 사용한다.

 

SQL은 데이터베이스에 접근하는 진정한 최적의 도구이다. 이런 까닭에 iBATIS는 관계형 데잍터베이스에 접근하는 1차적인 방법으로 SQL을 채택하였다. 동시에 iBATIS는 아래에서 논의할 저장 프로시저와 객체 관계 매핑(object/relational mapping, O/RM) 도구 등과 같은 다른 접근 방법들의 여러 장점들도 제공하고 있다.

 

옛날식의 저장 프로시저(Stored Procedure)

 

저장 프로시저는 아마도 관계형 데이터베이스로 애플리케이션 프로그램을 작성하는 가장 오래된 방법일 것이다. 저장 프로시저는 데이터베이스에서 실행시킬 SQL을 포함하고 있었다. 또 SQL과 함꼐 비즈니스 로직을 포함할 수도 있었으며 종종 실제로 포함하기도 했다. SQL과는 달리 저장 프로시저 언어는 절차적이며, 조건문이나 반복문같은 흐름 제어부를 가지고 있었다.

 

하지만 2-티어 애플리케이션은 성는과 확정성에 문제가 있었다. 게다가 2-티어 애플리케이션을 배포하는 것은 악몽이라 할만하다.

 

현대적인 저장 프로시저

 

요즘 저장 프로시저는 보통 중간 티어(middle tier)에서 호출되는 원격 프로시저처럼 사용되고 있으며, 성능에 관한 제약들이 커넥션 풀이나 데이터베이스의 자원을 관리함으로써 해결되었다.

 

저장 프로시저는 여전히 현대적인 객체 지향 애플리케이션의 데이터 접근 계층 전체를 구현하는데 사용할 수 있는 유효한 방법이다. 또 저장 프로시저는 다른 방법들에 비해 데이터베이스의 데이터를 가장 빨리 관리할 수 있는 성능상 이점을 가지고 있다. 하지만 단순한 성능만 아니라 여러가지 고려해야 할 사항이 더 있다. 저장 프로시저는 작성하고 테스트하고 배포하기가 어렵다. 더더욱 안 좋은 점은 데이터베이스가 개발 팀이 아닌 다른 팀의 영역인 경우가 종종 있고 엄격한 변경 관리가 어렵다는 점이다. 게다가 저장 프로시저는 비즈니스 로직을 제대로 구현하기에 기능이 충분치 못하다는 문제도 있다.

 

인라인 SQL

 

저장 프로시저의 한계를 극복하는 접근 방법으로 일반 프로그래밍 언어에 SQL을 내장시키는 방법이 있다. 인라인 SQL은 프로그래밍 언어와 잘 통합된다는 점에서는 상당히 멋지다. 해당 언어의 변수가 SQL의 파라미터로 직접 넘어갈 수도 있고, SQL 실행 결과도 비슷한 방식으로 변수에 직접 값을 넘겨줄 수 있다.

 

하지만 불행하게도 인라인 SQL은 폭넓게 받아들여지지 못했고, 몇몇 중대한 문제들 때문에 그 영역을 확장하기 어렵다.

 

동적 SQL

 

동적 SQL은 전처리기를 사용하지 않고 인라인 SQL을 다루는 방법이다. 대신, 현대 프로그래밍 언어에서 다른 문자 데이터를 다루는 것과 마찬가지로 SQL을 문자타입으로 다룬다.

 

동적 SQL은 유연하다는 장점이 있다. 서로 다른 파라미터나 동적인 애플리케이션의 기능에 따라서 실행 시간에 SQL이 변경될 수 있다.

 

동적 SQL은 현대 프로그래밍 언어에서 가장 많이 사용되는 관계형 데이터베이스 접근 방식이다. 대부분의 현대 프로그래밍 언어들은 데이터베이스 접근을 위한 표준 API를 포함하고 있다.

 

SQL이 문자열로 처리되다보니 한 줄로 작성하기엔 너무 길고 SQL 문자열을 여러줄로 분래해서 작성하고 연결할 필요가 있다. 연결된 SQL 구분은 가독성이 많이 떨어지고 유지보수와 작업을 어렵게 만든다.

 

객체 관계 매핑

 

객체 관계 매핑(ORM)은 SQL을 개발자의 책임 영역에서 완전히 제거함으로써 객체의 영구적인 저장을 단순화하도록 설계돼 있다. 대신 SQL은 자동 생성된다.

 

현대 ORM 도구들은 단순희 SQL을 자동 생성하는 것보다 더 많은 일을 한다. 이들은 전체 애플리케이션의 개발 생산성을 향상시키는 완전한 퍼시스턴스 계층 아키텍처를 제공해준다. 훌륭한 ORM들은 모두 트랜잭션 관리 기능을 제공한다. 또 로컬과 분산 트랜잭션 모두를 제어하는 간단한 API를 포함하고 있다. ORM 도구들은 일반적으로 불필요한 데이터베이스 접근을 피할 수 있도록 여러 다른 종류의 데이터를 다루는 다양한 캐시 전략을 제공한다.

 

이러한 기능들에도 불구하고 ORM이 모든 것을 해결해 주는 완벽한 솔루션은 아닌다. ORM이 모든 상황에 다 대응할 수는 없다. ORM  도구는 가정과 규칙(assumptions and rules)에 기반하고 있다. 어떤 객체 관계 솔루션도 모든 데이터베이스 각각에 존재하는 모든 기능과 성능 그리고 설계상의 미비점들을 지원해 줄 수는 없다.

 

1.1.2. iBATIS의 장점 이해하기

 

다른 솔루션이 제공하는 것과 유사하게 iBATIS가 제공하는 장점

방법	비슷한 이점	해결된 문제점
저장 프로시저	iBATIS는 SQL을 캡슐화하고 외부를 분리하여 애플리케이셔 ㄴ외부에 SQL을 둔다. iBATIS는 저장 프로시저와 비슷하지만 객체지향적인 API를 제공한다. iBATIS는 또한 저장 프로시저를 직접 호출하는 방법도 지원한다.	비즈니스 로직이 데이터베이스 밖에 있도록 한다. 배포가기 쉽다. 테스트하기 쉽다. 이식성이 좋다.
인라인 SQL	iBATIS는 SQL을 원형 그대로 작성할 수 있다. 문자열 연결이나 파라미터 값 설정, 결과값 가져오기 등이 불필요하다.	iBATIS는 애플리케이션 코드내에 삽입되지 않는다. 전처리기가 불필요하다. SQL의 일부가 아닌 모든 기능을 사용할 수 있다.
동적 SQL	iBATIS는 파라미터를 기반으로 하여 동적으로 쿼리를 구성하는 기능을 제공한다. 쿼리 구성 API는 필요없다.	iBATIS는 애플리케이션 코드에 섞인 연결된 문자열 블록으로 SQL을 작성할 필요가 없다.
객체/관계 매핑	iBATIS는 ORM 도구의 적재 지연(lazy loading), 조인해서 값 가져오기(join fetching), 실시간 코드 생성, 상속 등과 같은 많은 기능들을 동일하게 제공한다.	iBATIS는 어떠한 데이터 모델과 객체모델의 조합도 사용할 수 있다. 이들을 어떻게 설계 할지에 대한 제약이나 규칙 같은 것은 거의 없다.

 

 

 외부로 뺀 SQL

 

사용자 인터페이스 설계, 애플리케이션 프로그래밍 그리고 데이터베이스 관리 같은 서로 다른 프로그래밍 역할에 따라 다뤄지는 사항들은 서로 분리하는 것이 좋다. 비록 이러한 역할 모두를 한 사람이 하더라도 이렇게 분리하면 시스템의 특정 부분에 집중할 수 잇는 잘 계층화된 설계를 얻을 수 있다. 외부로 뺀 SQL은 SQL을 애플리케이션 소스 코드로부터 분리하여 둘 모두를 명확하게 유지할 수 있기 한다. 그렇게 함으로써 SQL은 상대적으로 특정 언어나 플랫폼에 독립적인 상태가 된다.

 

캡슐화된 SQL

 

캡슐화는 코드를 응집성 있는 모듈로 조직하는 것뿐만 아니라 또한 세부적인 구현을 숨기고 호출하는 코드에게 인터페이스만을 노출시키는 모듈화의 한 형태이다.

 

이러한 개념은 퍼시스턴스 계층으로도 확대 적용할 수 있다. SQL의 입력과 출력을 정의(이게 인터페이스이다)하고 애플리케이션의 다른 부분으로부터 SQL 코드를 숨겨서 SQL을 캡슐화 할 수 있다.

 

iBATIS는 SQL을 캡슐화하기 위해 XML을 사용한다. iBATIS는 XML을 사용해서 SQL 구문의 입력과 출력을 정의한다. 대부분의 SQL 구문은 하나 혹은 그 이상의 파라미터를 가지며 테이블 형태의 결과를 만들어 낸다. 이는 결과가 여러 칼럼과 레코드의 연속으로 이루어짐을 뜻한다. iBATIS는 파라미터와 실행 결과를 객체의 프로퍼티로 매핑하게 한다.

 

 1.2 iBATIS가 적합한 곳

 

대부분의 잘 설계된 소프르웨어는 계층화된 설계를 사용한다. 계층화된 설계란 애플리케이션의 기술적인 역할들을 응집성 높은 부분들끼리 묶어서 상세한 구현 방법을 특정 기술이나 인터페이스로부터 분리하는 것이다. 계층화된 설계는 견고한 어떤 프로그래밍 언어로도 구현할 수 있다.

 

 <그림> 디미터 법칙(Law of Demeter)을 따르는 전형적인 계층화 전략

 

* persistent(영속적인, 지속적인) - 메모리에 저장되어 있는 객체는 영속성(지속성)이 보장되지 않는다. 영속성을 보장하려면 파일에 저장(직렬화)하거나 DB에 저장하는 방법이 있다.

 

* 디미터 법칙 : 데메르데르 Demeter 그리스 신화에 나오는 여신. 곡무로가 수확의 여신, 제우스의 누이이자 아내, 디미터 법칙은 '디미터 프로젝트'를 수행하는 과정에서 발견된 법칙이라 그렇게 이름 붙여졌다고 함.

 

이런 계층화된 접근법은 디미터 법칙(Law of Demeter)에 의해 영향을 받은 것인다, 이것은 다음의 한 문장으로 나타낼 수 있다.

 

"각 계층은 다른 계층에 대해 오직 제한된 정보만을 가질 수 있다 : 오직 현재 계층에 인접한 계층에 대해서만."

 

이러한 개념은 각 계층이 오직 자기 바로 아래 계층과만 소통할 수 있다는 뜻이다. 이로 인해 의존성이 한 방향으로만 흐르는 것을 보장할 수 있다.

 

iBATIS는 퍼시스턴스 계층 프레임워크이다. 퍼시스턴스 계층은 애플리케이션의 비즈니스 로직과 데이터베이스 사이에 자리잡고 있다. 이러한 구분은 퍼시스턴스 계층이 비즈니스 로직 코드와 섞이지 ㅇ낳도록 보장하는 데 있어서 매우 중요하다. 이러한 구분은 객체 모델을 을 데이터베이스 설계와 무관하게 변경될 수 잇게 함으로써 코드의 유지보수성을 향상시켜준다.

 

비록 iBATIS가 퍼시스턴스 계층에 집중돼 있긴 하지만, 애플리케이션 아키텍처의 전체 계층을 이해하는 것도 중요하다.

 

1.2.1 비즈니스 객체 모델

 

비즈니스 객체는 애플리케이션의 비즈니스 계층을 제외한 다른 부분들의 토대가 되는 역할을 한다. 비즈니스 객체는 처리할 도메인을 객체 지향적으로 묘사한다. 이 때문에 비즈니스 객체 모델을 이루는 클래스를 도메인 클래스(domain class)라고 부르기도 한다. 다른 모든 계층들은 데이터를 나타내고 특정 비즈니스 로직의 기능을 수행하기 위해서 비즈니스 객체 모델을 사용한다.

 

애플리케이션 설계자들은 보통 다른 어떤 것보다도 비즈니스 객체 모델의 설계를 먼저 한다.

 

비즈니스 객체 모델 클래스는 약간의 로직을 포함할 수도 있다. 하지만 다른 계층, 특히 프리젠테이션 계층과 퍼시스턴스 계층에 접근하는 코드는 절대로 들어가면 안 된다. 게다가, 비즈니스 객체 모델은 절대로 다른 계층에 의존해서는 안 된-다. 다른 계층은 비즈니스 객체를 사용할 수 있지만, 그 반대는 절대로 안 된다.

 

iBATIS 같은 퍼시스턴스 계층은 보통 비즈니스 객체 모델을 사용하여 데이터베이스에 저장된 데이터를 나타낸다. 퍼시스턴스 계층의 메소드들은 파라미터나 반환 값으로 비즈니스 객체 모델의 도멘인 클래스들을 사용한다. 이 때문에 이 클래스들은 때때로 데이터 전송 객체(data transfer object)라고 부르기도 한다.

 

1.2.2 프리젠테이션 계층

 

프리젠테이션 계층은 애플리케이션의 데이터와 제어 화면을 출력하는 책임을 맡고 있다. 이는 모든 정보의 레이아웃을 지정하고 출력 형식을 정의하는 책임을 맡고 있음을 뜻한다.

 

웹 애플리케이션은 플랫폼에 독립적이고, 배포와 확장이 쉬운 장점을 가지고 있다. 리치 클라이언트는 훨씬 더 강력한 사용자 인터페이스를 제공해 주지만 배포가 다소 어렵고 웹 애플리케이션이 제공하는 성능이나 보안 수준을 제공하려면 더욱 ㅁ낳은 신경을 써야만 한다. 최근 들어 두 개념을 합친 복합적인 클라이언트로 웹 애플리케이션과 리치 클라이언트의 장점을 갖추려는 시도를 하고 있다.

 

그리고 모든 복합적인 프리젠테이션 계층의 멋진 축소판인 Ajax가 있다. 사실 꼭 비동기(asynchronous)이거나 XML을 이용할 필요는 없다. 그래서 요즘엔 Ajax는 간단히 '정말 멋진 자바스크립트를 매우 많이 이용해서 구성한 정말로 리치한 웹 기반 사용자 인터페이스' 정도의 의미로 사용된다.

 

iBATIS는 웹 애플리케이션과 리치 클라이언트 애플리케이션 그리고 복합적인 애플리케이션에서 모두 이용할 수 있다. 비록 일반적으로 프리젠테이션 계층이 퍼시스턴스 계층에 직접적으로 관여하는 경우는 없지만, 사용자 인터페이스에 대한 어떤 결정이 퍼시스턴스 계층에 대한 요구사항에 영향을 끼친다.

 

1.2.3 비즈니스 로직 계층

 

애플리케이션의 비즈니스 로직 계층은 해당 애플리케이션이 제공하는 포괄적인(coarse grained) 서비스들을 표현한다. 이러한 이유로 가끔 '서비스' 클래스라고 부르기도 한다. 상위 레벨에서는 누구라도 비즈니스 로직 계층의 클래스와 메소드들을 보고 시스템이 무엇을 하는지 이해할 수 있어야 한다.

 

비즈니스 기능들은 보통 매우 복잡하다. 이들은 한 개 이상의 클래스들을 다루고 데이터베이스, 메시지 큐 그리고 다른 시스템들을 포함해 많은 기반 컴포넌트들을 다룬다. 게다가 종종 하나의 비즈니스 기능이 여러 비즈니스 클래스에 관련되는 일도 발생해서 메소드가 대체 어느 클래스에 속해야 하는지 결정하기 힘든 경우도 생긴다. 이 때문에 포괄적으로 구현된 비즈니스 함수는 비즈니스 로직 계층에 속하는 클래스의 메소드로 따로 분리하여 구현하는 것이 낫다. 상세하게 구현된(fine grained) 비즈니스 로직을 관련된 도메인 클래스에 두는 것은 상관없다. 비즈니스 계층의 포괄적으로 구현된 서비스 메소드는 도메인 클래스에 있는 더 상세하게 구현된 순수 로직 메소드를 호출해 사용할 수 있다.

 

계층화된 아키텍처에서 비즈니스 로직 계층은 퍼시스턴스 계층 서비스를 사용하는 측이 된다. 비즈니스 계층은 데이터를 가져오거나 변경하기 위해서 퍼시스턴스 계층을 호출한다. 비즈니스 로직 계층은 트랜잭션을 구분짓는 훌륭한 장소이기도 하다. 왜냐하면 여러 가지의 서로 다른 사용자 인터페이스나 웹 서비스 같은 다른 인터페이스들을 사용하는 큰 덩어리 함수를 비즈니스 로직 계층에서 정의하기 때문이다.

 

1.2.4 퍼시스턴스 계층

 

퍼시스턴스 계층이 바로 iBATIS가 있는 곳이다. 객체지향 시스템에서 퍼시스턴스 계층의 주된 관심사는 저장소와 객체 가져오기, 또는 더 자세히 말하면 객체에 저장된 데이터라고 할 수 있겠다. 퍼시스턴스 계층은 데이터를 저장하기 위해 주로 관계형 데이터베이스 시스템과 소통한다. 퍼시스턴스 계층은 데이터가 어떻게 저장되고 어떻게 전송되는지에 대한 세부 사항을 숨겨야 한다.(추상화)

 

<그림> 퍼시스턴스 계층의 내부적인 계층 설계

 

 

추상 계층 (Abstraction Layer)

 

추상 계층의 역할은 퍼시스턴스 계층에 일관성 있고 의미 있는 인터페이스를 제공해 주는 것이다. 이것은 클래스와 메소드의 집합으로 퍼시스턴스 구현의 세부 사항에 대한 퍼사드(facade)의 역할을 한다. 추상 계층에 소속된 메소드는 특정 구현에 종속적인 파라미터를 요구하면 안 되고 특정 퍼시스턴스 구현에 종속적인 값을 리턴하거나 예외를 던져서도 안 된다. 적절한 추상 계층이라면 추상 계층을 수정하거나 추상 계층에 의존하는 다른 계층을 수정하는 일 없이 전체적인 퍼시스턴스 접근 방식을 변경하는 것이 가능해야 한다.

 

퍼시스턴스 프레임워크 (Persistence Framework)

 

퍼시스턴스 프레임워크는 드라이버와 소통하는 책임을 맡고 있다. 퍼시스턴스 프레임워크는 데이터를 저장하고 가져오고 수정하고 검색하고 관리하는 메소드들을 제공할 것이다. 추상 계층과는 달리 퍼시스턴스 프레임워크는 일반적으로 기반 저장소(stroage infrastructure)의 클래스에 종속적이다. 대부분의 인기 있는 프로그래밍 언어들은 관계형 데이터베이스를 다루는 표준 API를 가지고 있다. 표준 API들은 그 구현 결과물이 매우 완성도가 높고 일반적인 목적으로 사용할 수 있다. 하지만 이를 사용할 때는 반복적이고 부차적인 코드가 많이 필요하다. 이러한 이유로 표준 프레임워크를 기반으로 하여, 보다 특수한 상황ㅇ에서 보다 강력한 기능들로 확장한 많은 프레임워크들이 생겨났다. iBATIS는 자바와 .NET에서 일관성 있는 접근법을 통해 모든 관계형 데이터베이스를 전담하여 다루는 퍼시스턴스 프레임워크다.

 

드라이버 혹은 인터페이스 (Driver/Interface)

 

퍼시스턴스 프레임워크가 하는 일은 드라이버와 ㅌ오신하여 드라이버들 간의 차이점들을 최소화하고 간소화하는 것이다. iBATIS는 오직 관계형 데이터베이스만을 지원한다.

 

1.2.5 관계형 데이터베이스

 

무결성

 

데이터베이스는 강력한 데이터 타입 제약조건 엄수 그리고 트랜잭션 보장 등을 통해 무결성을 보장한다.

데이터베이스는 데이터 타입을 엄격하게 준수한다. 데이터 타입 엄수 뿐만 아니라 테이블에 다른 제약 조건도 줄 수 있다. 외래키 제약 조건은 테이블 간의 관계를 표현하기 위해 사용하며 이것은 관계형 데이터베이스 설계와 데이터 무결성에 필수적인 요소이다.

데이터베이스가 무결성을 관리하는 가장 중요한 방법 중의 하나로 트랜잭션을 이용하는 것이 있다. 트랜잭션을 이용하면 DBMS는 모든 관련된 데이터들이 일관성 있는 방식으로 수정됨을 보장할 수 있다.

 

성능

 

데이터베이스 성능은 세 가지 핵심 요인인 설계, 소프트웨어 튜닝 그리고 하드웨어에 의하여 좌우된다.

 

보안

 

관계형 데이터베이스 관리 시스템은 보안 측면에서 더 ㅁ낳은 이점을 제공해준다. 대부분의 상업용 품질을 갖춘 관계형 데이터베이스는 데이터 암호화 뿐만 아니라 매우 세세한 보안이 가능한 고급 보안 기능들을 갖추고 있다.

 

 

1.3 여러 종류의 데이터베이스로 작업하기

 

데이터베이스는 데이터베이스 설계나 규모보다는 다른 시스템들과의 관계에 따라 분류한다. 하지만 데이터베이스의 설계나 규모도 또한 관계가 어떠냐에 의해 좌우될 수 있다. 데이터베이스의 설계나 규모에 영향을 미치는 또 다른 요소로 그 데이터베이스가 얼마나 오래 되었는가가 있을 수 있다.

 

1.3.1 애플리케이션 데이터베이스

 

애플리케이션 데이터베이스는 일반적으로 가장 작고 단순하며 작업하기 가장 쉬운 편이다. 애플리케이션 데이터베이스는 보통 해당 프로젝트의 일부로써 애플리케이션과 나란히 설계하고 구현된다. 애플리케이션 데이터베이스는 외부의 영향은 거의 받지 않고, 대개 1~2개의 인터페이스만이 존재할 뿐이다.

 

<그림> 애플리케이션 데이터베이스 관계

 

iBATIS는 애플리케이션 데이터베이스의 퍼시스턴스 프레임워크로서의 역할을 아주 잘 수행한다. iBATIS의 단순함 때문에 개발팀은 애플리케이션 개발에 박차를 가할 수 잇을 것이다.

 

1.3.2 기업용 데이터베이스(Enterprise Database)

 

기업용 데이터베이스는 애플리케이션 데이터베이스보다 규모가 크고 외부의 영향도 훨씬 많이 받는다. 기업용 데이터베이스는 의존하는 다른 시스템들과의 관계가 더욱 복잡하다.

 

<그림> 기업용 데이터베이스 아키텍처의 예제

 

기업용 데이터베이스는 그 설계와 사용에 더 많은 제약 사항들을 내포하고 있다. 무결성, 성능 그리고 보안의 측면에서 신경써야 할 점들이 더욱 많다.

 

기업용 데이터베이스가 어떻게 설계되었든지 간에 애플리케이션 데이터베이스와 기업용 데이터베이스의 차이점을 쉽게 알아볼 수 있다. 애플리케이션 데이터베이스를 효율적으로 사용하고, 동일한 데이터베이스를 사용하는 다른 애플리케이션들과 조화를 잘 이루도록 하려면 운영 환경의 특정 제약 사항이 무엇인지 정확하게 이해하고 있어야 한다.

 

iBATIS는 기업용 데이터베이스 환경에서도 매우 잘 작동한다. iBATIS에서는 복잡한 데이터베이스 설계와 대용량 데이터를 최적으로 다룰 수 있게 도와주는 많은 기능들이 있다. iBATIS는 다중 데이터베이스와도 잘 작동하며 어떤 형태의 객체도 단 하나의 데이터베이스에서 가져온다고 가정하지 않는다. 또한 다중 데이터베이스가 단일 트랜잭션으로 묶이는 시스템처럼 복잡한 트랜잭션도 지원한다. 게다가 iBATIS는 실시간 트랜잭션 시스템뿐만 아니라 리포팅과 통합 시스템 구현에도 매우 잘 작동한다.

 

1.3.3 독접적 데이터베이스(Properietary Database)

 

iBATIS는 독점적 데이터베이스와 작업하는 데 매우 훌륭한 퍼시스턴스 계층의 역할을 한다. 종종 그런 데이터베이스들은 읽기만 가능한데, 그럴 때 개발자들은 특정 SQL만 실행 가능하게 제한함으로써 iBATIS 사용에 자신감을 가질 수 있게 된다. iBATIS는 개발자가 명시적으로 수정을 요청하지 않았는데 몰래 데이터를 수정하는 일은 하지 않는다. 만약 수정이 필요한 경우에도 독점적 데이터베이스는 데이터의 구조를 까다롭게 제한한다. iBATIS는 그런 경우에 맞는 특별한 업데이트 구문을 사용할 수 있게 해준다.

 

1.3.4 레거시 데이터베이스(Legacy Database)

 

레거시 데이터베이스는 일반적으로 선사 시대의 기업용 데이터베이스가 아직도 남아 있는 것이라 보면 된다.

iBATIS는 레거시 데이터베이스에도 도움이 될 수 있다. 작업할 시스템에 맞는 드라이버가 존재하는 한 iBATIS는 다른 어떤 데이터베이스들과도 동일한 방식으로 작업을 진행할 수 있게 해준다. 사실 iBATIS는 레거시 데이터베이스를 다루는 최적의 퍼시스턴스 프레임워크 중의 하나일 것이다. 왜냐하면 iBATIS는 데이터베이스 설계에 대해 어떤한 가정도 하지 않았기 때문에, 최악의 레거시 데이터베이스 설계에서조차도 잘 작동한다.

 

1.4 iBATIS는 데이터베이스의 공통적인 문제점들을 어떻게 다루나?

 

1.4.1 소유권과 제어권

 

현대 기업용 시스템 환경에서 데이터베이스를 사용함에 있어서 첫 번째이자 가장 어려운 점은 전혀 기술적인 문제가 아니다. 이것은 대부분의 기업들이 데이터베이스에 대한 소유권과 권한을 애플리케이션 개발팀에서 분리해 놓는다는 단순한 사실이다.

 

iBATIS는 데이터베이스 설계와 상호 작용에 대해 높은 유연성을 보여준다. 데이터베이스 관리자들과 SQL 프로그래머들은 iBATIS를 이해하는 데 어려움이 엇을 것이다. iBATIS는 보이지 않는 곳에서 특별한 처리를 하지 않고, 있는 그대로의 SQL을 볼 수 있게 해주기 때문이다.

 

1.4.2 여러 이종 시스템들에 의한 접근

 

서로 다른 시스템들이 서로 다른 방식으로 하나의 데이터베이스에 접근하고 사용한다.

중요한 것은 데이터베이스가 한 개 이상의 시스템에 의해 사용되면 일이 어려워진다는 것을 알아야 한다. iBATIS가 여러 방식으로 여기에 도움을 준 수 있다. 우선 iBATIS는 트랜잭션 시스템, 일괄 처리 시스템 그리고 리포팅 시스템 등을 포함한 모든 종류의 시스템에서 잘 작동하는 퍼시스턴스 프레임워크이다. 이는 어떠한 시스템이 데이터베이스에 접근하든지 상관없이, iBATIS는 훌륭한 도구라는 뜻이다. 두 번째로, 여러분이 iBATIS를 사용할 줄 안다면, 혹은 자바 같은 견고한 시스템만 사용할 줄 알아도, 여러 다른 시스템들과 소통하는 분산 캐시를 사용할 수 있을 것이다. 마지막으로, 너무 복잡한 경우에는 간단하게 iBATIS의 캐시 기능을 꺼버리고, 데이터베이스를 함께 사용하는 다른 데이터베이스의 쿼리가 캐시 동시 사용을 고려하지 않았더라도 상관없이 완벽하게 작동하는 명시적인 쿼리와 수정 구문을 작성하면 된다.

 

1.4.3 복잡한 키와 관계들

 

iBATIS는 어떠한 복잡한 키 정의나 관계도 다룰 수 있다. 비록 데이터베이스 설계를 제대로 하는 것이 가장 좋겠지만, iBATIS는 의미 없는 키, 자연키, 복합키 혹은 아예 키가 없는 경우의 테이블까지도 다룰 수 있다.

 

1.4.4 비정규화된 혹은 과도하게 정규화된 모델

 

iBATIS는 비정규화된 모델과 과도하게 정규화된 모델을 둘 다 잘 다룬다. iBATIS는 데이터베이스와 객체 모델의 크기에 대해 어떠한 가정도 하지 않으며, 또한 두 모델이 완전히 동일한지 혹은 서로 그다지 비슷하지 않은지도 가정하지 않는다. iBATIS는 객체 모델과 관계 데이터 모델의 분리를 매우 잘 정의하고 있다.

 

1.4.5 빈약한 데이터 모델(skinny Data Model)

 

빈약한 데이터 모델이란 기본적으로 각 테이블을 일반적인 데이터 구조체로 만들어서 이름과 값의 쌍으로 된 데이터 집합을 저장하는 것이다.

 

비록 기업용 데이터베이스에서 빈약한 데이터 모델을 만나게 되더라도, iBATIS는 문제 없이 이 상황을 처리할 수 있다. 어떤 필드가 존재하는지 알 수 없기 때문에, 클래스를 빈약한 데이터 모델에 매핑하는 것은 매우 어렵고 어떨 때는 불가능하기도 하다. 운이 좋다면 이것들을 Hashtable에 매핑할 수 있을텐데, 다행히 iBATIS는 그런 기능을 지원한다. iBATIS를 이용하면, 모든 테이블을 사용자 정의 클래스로 매핑할 필요가 없다. iBATIS는 관계형 데이터를 원시타입, 맵, XML 그리고 사용자 정의 클래스로 매핑하는 기능을 지원한다. 이러한 커다란 유연성으로 인해, iBATIS는 빈약한 데이터 모델을 포함한 여러 복잡한 데이터 모델에 대해서 매우 효율적으로 작동한다.

 

1.5 요약

 

iBATIS는 모든 문제를 해결하려 하기 보다는, 가장 중요한 문제들을 집중해서 해결하도록 설계된 복합적인 솔루션이다. iBATIS는 여러 접근 방법들로부터 아이디어를 차용했다. iBATIS는 객체 관계 매핑 도구들로부터 캐싱이나 적재 지연 그리고 고급 트랜잭션 관리 기능 등을 포함한 많은 개념들을 차용해 왔다.

 

애플리케이션 아키텍처에서 iBATIS는 퍼시스턴스 계층에 속한다. iBATIS는 애플리케이션의 모든 계층에서 필요로 하는 것들을 쉽게 구현할 수 있는 기능을 제공함으로써 다른 계층들을 지원하기도 한다.

 

iBATIS는 어떤 규모나 목적을 가진 데이터베이스와도 잘 작동한다.