mybatis와 ibatis의 차이점 :
1. MyBatis는 인터페이스 바인딩을 구현하여 IBATIS2.X에서 <br />를 사용하는 것이 더 편리합니다 . DAO 구현 클래스의 XML 매핑 파일에 해당하는 XML 매핑 파일을 지정해야합니다.
MyBatis는 DAO 인터페이스 및 XML 매핑 파일의 바인딩을 구현하고 우리를 위해 인터페이스의 특정 구현을 자동으로 생성하여보다 쉽고 편리하게 만듭니다.
이것은 mybatis의 가장 중요한 개선이라고 할 수 있습니다.
알아채다:
MyBatis는 구성을 단순화하기 위해 인터페이스에서 직접 주석 구성의 사용을 지원하지만
그러나 여전히 XML 구성 방법을 사용하는 것이 좋습니다. 결국, 주석의 구성 방법은 제한되어 있으며 코드는 너무 침습적입니다. XML 구성 메소드를 사용 하여만 myBatis의 장점을 반영 할 수 있습니다.
2. 객체 관계 매핑의 개선은 더 효율적입니다 <br /> 나는 ibatis2.x를 사용하는 많은 친구들이 iBatis의 XML 매핑 파일을 통해 객체 간의 관계 매핑을 인식하지 못한다고 생각합니다. IBATIS2.X는 "Necked Query"를 사용하여 쿼리 문의 직접 조립을 통해 객체 간의 관계를 실현하기 때문에 DAO 또는 서비스의 캡슐화와 동일하기 때문에 실제로는 그렇게 할 필요가 없습니다.
그러나이 방법에는 "n+1 쿼리 문제"가 있습니다.
요약하면 N+1 쿼리 문제는 다음과 같이 발생할 수 있습니다.
? 결과 목록 (+1)을 얻기 위해 별도의 SQL 문을 실행합니다.
? 반환 된 각 레코드에 대해 각 로딩에 대한 세부 사항을로드하기 위해 쿼리 문을 실행합니다 (즉, N).
이 문제로 인해 수백 개의 SQL 문이 실행될 수 있습니다. 이것은 일반적으로 예상되지 않습니다.
MyBatis에서 IBATIS2.X의 "Necked Query"메소드와 호환되는 것 외에도 직접 "Necked result"메소드도 제공하며, 이는 문장 SQL을 통해 쿼리 된 DTO 객체를 필요한 객체를 자동으로 캡슐화하는 것과 동일합니다.
특정 구현 방법은 MyBatis 공식 사용자 설명서를 직접 참조하고 여기에 설명하지 마십시오.
그러나 실제로이 개선으로 인한 이점은 매우 제한적입니다. 페이징을 사용할 때는이 방법이 작동하지 않거나 중첩 된 물체의 결과 세트는 페이징이 허용되지 않습니다. 이것은 mybatis 프레임 워크 (org.apache.ibatis.executor.resultset.nestedresultsethandler의 34 줄)에서 명확하게 제한되었으며 실제 프로젝트에서 페이징이 필요한 경우가 많이 있습니다 ...
신중하게 생각한다면,이 시점에서 쿼리 된 레코드 수는 실제 반환 오브젝트의 크기와 같지 않지만 일대일 매핑이 허용되지 않는 이유를 이해하지 못하기 때문에 구성 파일을 통해 1 대 마니 매핑이 페이징 할 수 없습니다. 어쩌면 일대일이 일대일 특별한 경우이기 때문에 프레임 워크를 설계 할 때이 특별한 경우를 다루는 것은 고려되거나 어렵지 않습니다.
3. Mybatis는 강력한 Ognl 기반 표현식을 사용하여 다른 요소를 제거하여 Struts2에 익숙한 사람들은 Ognl 표현에 익숙하지 않아야합니다.
MyBatis는 OGNL 표현식을 사용하여 구성 파일의 복잡성을 단순화하고 사용하기가 간단합니다.
어쩌면 더 걱정할 수도 있습니다
Mybatis는 인터페이스 바인딩을 구현하여 사용하기 편리합니다.
IBATIS/MYBATIS 3은 새로운 기능인 주석을 제공합니다.