최대 절전 모드 대 iBATIS

최대 절전 모드 대 iBATIS

---

신제품 리엔지니어링을 위해 Java에서 최상의 프레임 워크를 선택하는 중입니다. 고려 사항은 모델에 대한 데이터베이스에 구애받지 않는 접근 방식을 사용하는 것이므로 Struts + Spring과 iBATIS 또는 Hibernate 사이의 옵션에 대해 작업하고 있습니다. 둘 다 끈기를 제공하므로 가장 좋은 조언을 부탁드립니다.

---

Ibatis와 Hibernate는 완전히 다른 짐승입니다.

내가 보는 경향은 이것이다 : Hibernate는 뷰가 더 객체 중심적 일 때 더 잘 작동합니다 . 그러나 데이터베이스 중심적 이라면 Ibatis가 훨씬 더 강력한 선택입니다.

스키마를 완전히 제어하고 있고 처리량이 매우 높지 않은 경우 Hibernate가 매우 잘 작동 할 수 있습니다. 개체 모델은 매우 편리 코드 만에 만드는 거대한 복잡성 비용.

상당히 복잡한 SQL 쿼리를 작성해야하는 "레거시"데이터베이스 스키마를 다루는 경우 Ibatis가 더 잘 작동 할 가능성이 있습니다.

HQL (Hibernate Query Language)은 여러분이 배워야 할 또 다른 언어이며, 그 후에도 여전히 SQL을 작성해야하는 경우를 찾을 수 있습니다 . 또한, Hibernate가 고성능 SQL 쿼리를 생성하도록하기 위해 XML, 속성, 주석 등의 올바른 조합을 파악하는 데 반나절을 소비 할 가능성이 있습니다.

이 질문에 대한 보편적 인 "A가 B보다 낫다"는 대답은 없습니다.

---

달성하려는 것을 고려하십시오. 일반적으로 명령 쿼리 응답 분리 모델은 복잡한 도메인에 적합합니다.

그 이유는 일반적으로 다음 두 가지 중 하나를 수행하려고하기 때문입니다.

1. 복잡한 도메인 엔티티 생성 / 업데이트 / 삭제
2. 분석 가져 오기 쿼리 실행 (예 : 합계 / 집계 쿼리)

Hibernate 는 케이스 1에서 잘 작동하므로 POJO를 만들고 지속 / 업데이트 할 수 있습니다. 또한 도메인이 상당히 크지 않는 한이 작업을 빠르게 수행합니다.

myBatis 는 답변을 원하는 쿼리 (케이스 2) 가져 오기에 적합합니다. Hibernate는 전체 개체 그래프를로드하려고 시도하며 대규모 도메인에서 계속 작동하려면 LazyLoading 트릭을 사용하여 쿼리 튜닝을 시작해야합니다. 반대로 일부 분석 POJO 페이지를 원하면 동일한 쿼리의 myBatis 구현은 사소한 것입니다.

이 때문에 myBatis 는 SELECTS에서 Hibernate보다 빠릅니다 .

이 두 경우는 도메인 데이터를 변경하려는 명령 과 일부 데이터를 가져 오려는 응답 의 차이 입니다.

따라서이 두 가지 경우와 애플리케이션이 수행하는 작업을 고려하십시오. 간단한 도메인이 있고 정보 만 가져 오면 myBatis를 사용하십시오. 복잡한 도메인이 있고 엔티티가 지속되는 경우 Hibernate를 사용하십시오. 둘 다 수행하는 경우 하이브리드 접근 방식을 고려하십시오. 그것이 우리가 프로젝트에서 사용하는 것인데,이를 통제하기 위해 수천 개의 엔티티가 있습니다. ;)

---

Cletus는이 비교를 요약하는 데 큰 역할을했습니다. Hibernate는 데이터 모델을 제어 할 때 잘 작동하고 더 객체 중심적이지만 iBATIS는 기존 데이터베이스와 통합해야하고 더 데이터 중심적 일 때 잘 작동합니다.

또한 Hibernate는 학습 곡선이 조금 더 많다고 생각합니다. iBATIS를 사용하면 Hibernate에서 더 많은 "마법"이 발생하는 동안 무슨 일이 일어나고 있는지 쉽게 알 수 있습니다. 즉, 초보자는 iBatis를 사용하고 이해하기가 더 쉽다는 것을 알게 될 것입니다.

그러나 iBatis를 선호해야한다는 것은 아닙니다. iBatis와 Hibernate는 위에서 말한 것과 다릅니다.

그리고 Hibernate를 선택한다면 Hibernate Annotations에서 제공하는 표준화 된 JPA 및 EJB 3.0 (JSR-220) 객체 / 관계형 매핑 주석을 사용하는 것이 좋습니다.

---

ORM 대 지속성 프레임 워크

Hibernate는 Java 클래스를 데이터베이스 테이블에 매핑하는 객체 관계 매핑 프레임 워크 (ORM)입니다. MyBatis는 ORM이 아닌 지속성 프레임 워크입니다. SQL 문을 Java 메서드에 매핑합니다.

데이터베이스 스키마

Hibernate는 Java 모델에 따라 데이터베이스 스키마를 생성하거나 유효성을 검사 할 수 있지만 MyBatis에는 그러한 기능이 없습니다. 또한 In-memory DB를 사용할 때 테스트 환경에 편리합니다. 관련 토론 :

• MyBatis가 데이터베이스 스키마를 생성 할 수 있습니까?

은닉처

Hibernate에는 비활성화 할 수없는 첫 번째 수준 캐시가 있습니다. ORM을 통해 항목을 쿼리 한 다음 SQL로 직접 삭제하면 캐시에 남아 있음을 의미합니다. 캐시를 명시 적으로 지워 데이터베이스에서 가장 최근에 업데이트 된 결과를 얻을 수 있습니다. 관련 토론 :

• Jpa & Hibernate는 DB에서 비동기 적으로 변경되는 데이터를로드합니까?
• Hibernate에서 1 단계와 2 단계 캐싱은 무엇입니까?

낙관적 잠금 관리

또한 낙관적 잠금 관리에 대한 차이점이 있습니다.

MyBatis는 @Version 주석이있는 Hibernate / JPA와 같은 ORM 도구와 달리 낙관적 동시성 제어를 기본적으로 지원하지 않습니다.

관련 토론 :

• 낙관적 동시성 제어
• iBatis를 통해 UPDATE에서 동시성 문제를 방지하는 방법

지연 로딩

Hibernate는 지연 로딩으로 표시된 객체를 제외하고 전체 객체 그래프를로드하려고합니다. myBatis는 SQL 쿼리에 따라 데이터를로드합니다. 지연로드는 성능을 향상시킬 수 있지만 <property name="hibernate.enable_lazy_load_no_trans" value="true" />속성 과 함께 사용하면 연결 누수가 발생할 수 있습니다 . 관련 토론 :

• org.hibernate.LazyInitializationException-프록시를 초기화 할 수 없음-세션 없음
• hibernate.enable_lazy_load_no_trans로 Hibernate Lazy-Init 문제 해결

Hibernate 세션 관리

저장, 업데이트 또는 삭제와 같은 엔티티 작업은 Hibernate Session을 통해 수행됩니다 . Hibernate detached entity passed to persist와 관련된 다른 현상 을 피하기 위해 적절한 Hibernate Session 관리 전략을 구현하는 방법을 잘 이해해야합니다 .

Sometimes it may take more time trying to understand underlying Hibernate behavior than add a little bit more work and write raw SQL statements for myBatis.

Cascading

Hibernate provides cascading, orphan removal and other features for object graphs while they not present in myBatis - to implement them you'll need to write SQL queries explicitly.

Queries

In myBatis you'll write almost plain SQL queries. Hibernate has multiple options to form query: SQL, HQL, Criteria API. Sometimes it may be suitable to use Criteria API when you have many optional fields in criteria. It would provide more structured approach to form query and maybe avoid related mistakes.

---

Hibernate is an ORM, meaning (at its most basic level) it maps instances of java objects to actual rows in a database table. Generally, for pojo's retrieved via Hibernate: any manipulations and modifications to these pojo's will appear in the database. Hibernate will generate and execute the relevant SQL at an appropriate time.

Mybatis (at its most basic level) is simply a tool for piecing together and executing SQL that is stored in xml files. It does not map instances of Java objects to rows in a database table, rather it maps Java methods to SQL statements, and therefore it is not an ORM. It can also return pojo's of course, but they are not tied to any kind of a persistence context.

Both tools do a lot more than described above, but one is an ORM and one is not.

The criteria to enable you to choose which one to use, I believe, depends critically on the database model you have to work with.

For example imagine a large sprawling schema, representing some insurance model. Developers are required to retrieve data, and interact with that data in a way that meets the business at hand.

Developer's come on go, and would never be expected to have the requisite business knowledge to write all the sql by hand (which Mybatis would require). Hibernate would suit a scenario like that.

Business analysts define the datamodel, the entities, the relationships and the interactions, as is their expertise. Java developer's then use Hibernate to "walk the model". The business developer's can become very productive quickly without the need to write complicated error prone sql to run on a very complicated schema.

In my expierence, both Hibernate and Mybatis are used regularly on the same project.

Where Hibernate is being used for

• General C.R.U.D functionality
• 'Walking' the 'domain object' relational model
• Session management

and where Mybatis is being used for

• ad hoc queries
• kick off (and interact with) stored procedures
• support very specific or intricate queries
• support complicated search queries, where search criteria is dynamic, and paging of results

---

if you're already using Spring, I would start with Spring JDBC rather than plunging right into Hibernate or iBatis. If you write your persistence tier in terms of interfaces, you should have no problem switching implementations after you've gotten Hibernate or iBatis under your belt.

There's no reason why it has to be an "all or none" decision. Use what's best for your situation.

참고URL : https://stackoverflow.com/questions/1984548/hibernate-vs-ibatis