IBatis와 Hibernate의 차이점
1. 소개
Hibernate는 현재 가장 널리 사용되는 O/R
매핑 프레임워크입니다. sf.net에서 시작되었으며 현재는 Jboss의 일부입니다. iBATIS는 또 다른 뛰어난 O/R
매핑 프레임워크로, 이제 이름이 myBATIS로 변경되었습니다. 현재는 Apache의 하위 프로젝트입니다. Hibernate "O/R"과 비교할 때, iBATIS
는 "Sql Mapping"의 ORM 구현입니다.
Hibernate는 데이터베이스 구조의 비교적 완전한 캡슐화를 제공합니다.
매핑은 POJO와 데이터베이스 테이블 간의 매핑뿐만 아니라 SQL의 자동 생성 및 실행을 구현합니다. 프로그래머는 종종 POJO와 데이터베이스 테이블 간의 매핑 관계만 정의하면 되며, 그런 다음 Hibernate에서 제공하는 방법을 통해 지속성 계층 작업을 완료할 수 있습니다. 프로그래머는 SQL에 능숙할 필요도 없습니다. Hibernate/OJB는 지정된 스토리지 로직을 기반으로 해당 SQL을 자동으로 생성하고 실행을 위해 JDBC 인터페이스를 호출합니다.
iBATIS의 초점은 POJO와 SQL 간의 매핑 관계입니다. 즉, iBATIS는 런타임 시 프로그래머를 위한 SQL 실행을 자동으로 생성하지 않습니다.
특정 SQL은 프로그래머가 작성해야 하며, SQL에 필요한 매개변수와 반환된 결과 필드는 매핑 구성 파일을 통해 지정된 POJO에 매핑됩니다. iBATIS에서 제공하는 ORM 메커니즘을 사용하면 비즈니스 로직 구현자
는 순수 Java 개체에 직면하게 됩니다. 이 계층은 기본적으로 특정 데이터 작업을 위해 Hibernate를 통해 ORM을 구현하는 것과 동일합니다.
, Hibernate는 자동으로 SQL 문을 생성하는 반면 iBATIS는 개발자가 특정 SQL 문을 작성하도록 요구합니다.
Hibernate와 비교하여 iBATIS는 SQL 개발 작업량과 데이터베이스 이식성을 저하시켜 시스템 설계에 더 큰 자유를 제공합니다.
2. 둘 사이의 비교
1) iBATIS는 매우 간단하고 배우기 쉬운 반면, Hibernate는 상대적으로 복잡하고 임계값이 더 높습니다. 문서를 읽은 후 반나절 정도 지나면 iBATIS를 마스터할 수 있습니다. Hibernate는 마스터하는 데 3배 더 많은 시간이 걸릴 수 있습니다.
2) 둘 다 뛰어난 오픈 소스 제품입니다. 하지만 Hibernate는 이제 주류 O/R 매핑 프레임워크로, 문서의 풍부함, 제품의 완성도, 버전 개발 속도 등에서 iBATIS보다 빠릅니다.
3) 시스템이 2차 개발 중이고 데이터베이스 구조를 제어 및 수정할 수 없는 경우에는 Hibernate보다 iBATIS의 유연성이 더 적합할 것입니다.
4) 시스템에는 엄청난 양의 데이터 처리와 극도로 까다로운 성능 요구 사항이 있습니다. 이는 종종 시스템 성능 설계 지표를 달성하기 위해 고도로 최적화된 SQL 문(또는 저장 프로시저)을 사용해야 함을 의미합니다. 이 경우 iBATIS는 더 나은 제어성과 성능을 갖게 됩니다. iBatis는 Hibernate보다 SQL을 최적화하기가 더 쉽습니다. 일반적인 시스템 성능의 병목 현상이 데이터베이스라는 점을 고려하면 이는 iBatis의 매우 중요한 장점입니다.
5) iBatis는 세분화된 최적화를 수행할 수 있습니다.
예를 들어, 여러 개 또는 수십 개의 필드가 있는 테이블이 있는데, iBatis는 매우 간단합니다. /p>
SQL을 실행합니다: UPDATE TABLE_A SET column_1=#column_1# WHERE
id=#id# 그러나 Hibernate를 사용하는 것이 더 번거롭습니다. 기본적으로 Hibernate는 모든 필드를 업데이트합니다. 물론, 최대 절전 모드에는 수정된 필드만 저장되도록 제어하는 옵션이 있습니다.
iBatis를 사용할 때 장점은 데이터베이스에서 더 적은 양의 데이터를 읽고 트래픽을 저장할 수 있다는 것입니다. TABLE_WITH_A_LOT_OF_COLUMN WHERE...
일반적으로 Hibernate는 모든 필드를 선택합니다. 예를 들어 위의 테이블에는 비교적 큰 필드 1개 또는 2개(varchar(255)/text)를 포함하여 8개의 필드가 있습니다. 위 장면에서 내가 왜 그것을 선택했는가?
최대 절전 모드를 사용하는 경우 전체 도메인 개체를 한 번에 로드해야 하는 곳이 여전히 많기 때문에 불필요한 두 필드를 지연 로드로 설정할 수 없습니다. 이때 이바티스의 장점이 드러날 수 있다.
Hibernate에는 javabean/map/object[](leelun/cjmm에게 감사드립니다)를 생성하는 또 다른 솔루션이 있지만 이로 인해 많은 수의 중복 클래스가 생성될 수 있습니다. map/object[] 방법이 좋을 것입니다. 저는 이 방법을 선호합니다.
기록(객체)을 업데이트해야 하는 경우, 최대 절전 모드를 사용하는 경우 지금 객체를 선택한 다음 업데이트해야 합니다. 이것은 데이터베이스에 대한 단지 두 개의 SQL입니다. 그리고 iBatis에는 SQL 업데이트만 필요합니다. 데이터베이스와의 상호 작용을 줄이는 것은 성능 향상에 매우 중요합니다.
6) iBatis는
직접 작성한 SQL 문이 필요하고 그 중 일부를 생성할 수도 있지만, Hibernate는 기본적으로 자동으로 생성할 수 있으며 때때로 일부 Hql을 작성할 수도 있습니다. 동일한 요구 사항에 대해 iBATIS의 작업량은 Hibernate의 작업량보다 훨씬 큽니다. 마찬가지로, 데이터베이스 필드 수정과 관련된 경우 Hibernate는 매우 적은 위치를 수정하는 반면 iBATIS는 해당 SQL
매핑 위치를 하나씩 수정합니다.
7) 개발 측면에서는
개발 효율성 측면에서는 둘이 거의 비슷해야 한다고 생각합니다.
유지보수성 측면에서는 둘 다 비슷해야 한다고 생각합니다. 아이바티스가 더 좋습니다. iBatis의 SQL은 별도의 파일에 저장되기 때문입니다. Hibernate는 경우에 따라 Java 코드에 sql/hql을 저장할 수 있습니다.
8) 운영 효율성
캐시를 고려하지 않으면 iBatis는 최대 절전 모드보다 약간 또는 훨씬 더 빠릅니다(실제 상황에 따라 달라질 수 있음).
9) 다양한 데이터베이스 유형을 지원합니다. 다양한 데이터베이스 유형에 대한 iBatis의 지원은 충분하지 않습니다. 개발하려는 시스템이 데이터 쌍 간에 이식되어야 하는 경우 최대 절전 모드를 사용하는 것이 더 나을 수 있습니다.
10) 기본 캐시를 지원합니다. iBatis의 기본 캐시 지원은 충분하지 않지만 hibernate의 캐시 지원은 실제로 그다지 좋지 않고 매우 복잡합니다. 특히 동시성이 큰 애플리케이션의 경우. 그래서 저는 캐시를 직접 관리하는 것을 선호합니다.
11) 데이터베이스 필드의 일대일 매핑으로 얻은 PO(영구 객체)는 Hibernte와 같은 객체 기반 매핑으로 얻은 PO와 완전히 다릅니다. Hibernate에 의해 매핑된 PO가 아닌 플랫은 3차원 객체 상속, 집합 및 기타 관계를 표현할 수 있으며 이는 전체 소프트웨어 시스템의 디자인 아이디어에 직접적인 영향을 미칩니다.
12) 가장 중요한 문장은 iBATIS 작성자가 말한 것입니다. 새 프로젝트를 시작하고
객체 모델과 데이터베이스 설계를 완전히 제어할 수 있다면,
제3자 데이터베이스(예: 공급업체 제공)에 액세스하거나 기존
>
데이터베이스 또는 정말 잘못 설계된 데이터베이스라면 O/R
매퍼가 상황을 처리하지 못할 수도 있습니다.
SQL 매퍼가 유용할 것입니다.< /p>
3. 선택 방법
Hibernate 또는 iBATIS를 선택하는 이유가 있습니다:
Hibernate는 강력한 기능, 우수한 데이터베이스 독립성 및 O/R 매핑 강력한 능력을 가지고 있습니다. . 당신이 Hibernate에 상당히 능숙하고 Hibernate를 적절하게 캡슐화한다면, 당신 프로젝트의 전체 지속성 계층 코드는 작성할 코드가 거의 없이 매우 간단할 것이며 개발 속도는 매우 빨라질 것이며 이는 매우 즐겁습니다.
Hibernate의 단점은 학습의 문턱이 낮지 않고 숙달의 문턱이 훨씬 높다는 점입니다. 또한 O/R 매핑 설계, 성능과 개체 모델의 균형 조정 방법 등이 필요합니다. Hibernate를 잘 활용하는 방법은 경험과 능력이 탄탄한 경우에만 가능합니다.
iBATIS는 시작하기 쉽고 즉시 사용할 수 있습니다. 데이터베이스 쿼리에 대한 자동 개체 바인딩 기능을 제공하고 개체 모델 요구 사항이 높지 않은 프로젝트의 경우 매우 완벽합니다. .
iBATIS의 단점은 프레임워크가 여전히 상대적으로 단순하고 함수가 여전히 누락되어 있다는 점입니다. 데이터 바인딩 코드가 단순화되었음에도 불구하고 기본 데이터베이스 쿼리 전체는 여전히 직접 작성해야 하며, 워크로드가 상대적으로 크고, 빠른 데이터베이스 수정에 쉽게 적응할 수 없습니다.