마이바티스와 이바티스의 차이점

Mybatis와 Ibatis의 차이점:
1. Mybatis는 사용하기 더 편리한 인터페이스 바인딩을 구현합니다.
ibatis2.x에서는 특정 xml 매핑 파일에 해당하는 xml 매핑 파일을 지정해야 합니다.
Mybatis는 DAO 인터페이스와 xml 매핑 파일의 바인딩을 구현하고 인터페이스의 특정 구현을 자동으로 생성하므로 더 문제가 없고 사용하기 편리합니다.
이것은 마이바티스의 가장 중요한 개선점이라고 할 수 있습니다.

참고:
Mybatis는 구성을 단순화하기 위해 인터페이스에서 직접 주석 구성을 사용하는 것을 지원하지만
xml 구성을 계속 사용하는 것이 좋습니다. 결국 주석 구성 방법은 기능이 제한되어 있고 코드가 너무 방해적입니다. xml 구성 방식을 사용해야만 마이바티스의 장점이 반영될 수 있다

2. 객체-관계형 매핑 개선 및 효율성 향상
ibatis2.x를 사용하는 많은 친구들이 이를 통해 구현하지 않은 것으로 생각됩니다. ibatis의 xml 매핑 파일 객체 간의 관계 매핑. 실제로 ibatis2.x는 쿼리문의 직접 조립을 통해 개체 간의 관계를 실현하기 위해 "중첩 쿼리" 방법을 사용하기 때문에 실제로 그렇게 할 필요가 없습니다. 그 효과는 DAO 또는 Service에 캡슐화하는 것과 같습니다.
그러나 이 방법에는 "N+1 쿼리 문제"가 있습니다.
간단히 말하면 N+1 쿼리 문제는 다음과 같은 이유로 발생할 수 있습니다.
결과 목록(즉, +1)을 얻기 위해 단일 SQL 문을 실행했습니까?
? 반환된 각 레코드에 대해 쿼리를 실행하여 각 레코드(N)에 대한 세부 정보를 로드합니다.
이 문제로 인해 수백 또는 수천 개의 SQL 문이 실행됩니다. 이는 일반적으로 예상되지 않습니다.

Mybatis에서는 ibatis2의 "중첩 쿼리" 방법과 호환될 뿐만 아니라 dto 개체가 필수 개체에 자동으로 캡슐화됩니다.
여기서 설명하지 않는 구체적인 구현 방법은 Mybatis 공식 사용자 매뉴얼을 참조하세요.

그러나 실제로 이러한 개선의 이점도 매우 제한적입니다. 페이징을 사용할 때 이 방법이 작동하지 않거나 중첩된 개체의 결과 집합이 페이징을 허용하지 않기 때문입니다. 이 점은 마이바티스 프레임워크(org.apache.ibatis.executor.resultset.NestedResultSetHandler의 34번째 줄)에서 명확히 제한되어 있으며, 실제 프로젝트에서는 페이징이 필요한 경우가 많습니다...
잘 생각해보세요, 이때 쿼리되는 레코드의 개수가 실제 반환되는 객체의 크기와 같지 않기 때문에 일대다 매핑이 ​​구성 파일을 통해 페이징될 수 없는 것은 사실이나, 왜 일대일 매핑인지는 명확하지 않습니다. 매핑이 허용되지 않습니다. 아마도 일대일은 일대다의 특수한 경우이기 때문일 것인데, 프레임워크를 설계할 때 이 특수한 경우를 처리하는 것을 고려하지 않았거나 어렵지는 않았을 것입니다.

3. MyBatis는 다른 요소를 제거하기 위해 강력한 OGNL 기반 표현식을 사용합니다.
struts2에 익숙한 사람은 OGNL 표현식에 익숙해야 합니다.
MyBatis는 구성을 단순화하기 위해 OGNL 표현식을 사용합니다. 사용합니다.

더 우려되는 점은
마이바티스가 인터페이스 바인딩을 구현해 더욱 사용하기 편리하다는 점이다.
iBatis/MyBatis 3에서는 주석이라는 새로운 기능을 제공합니다.

Mybatis와 Ibatis의 차이점에 대한 더 많은 글은 PHP 중국어 홈페이지를 주목해주세요!