QueryDSL, MyBatis, JdbcTemplate 타입 안정성에 대한 생각

QueryDSL의 타입 안정성에 대한 생각

아래는 QueryDSL 레퍼런스에서 인용한 글입니다.

Querydsl의 핵심 원칙은 타입 안정성(Type safety) 이다. 도메인 타입의 프로퍼티를 반영해서 생성한 쿼리 타입을 이용해서 쿼리를 작성하게 된다. 또한, 완전히 타입에 안전한 방법으로 함수/메서드 호출이 이루어진다.

 

QueryDSL은 개발자가 직접 쿼리를 작성하지 않고 메서드 체이닝을 이용한 메서드를 통해 QueryDSL이 자동으로 쿼리를 생성하여 실행합니다. QClass가 정적 타입 기반의 안전한 쿼리 작성 방식을 위한 클래스이므로 컴파일 시 타입 안정성을 보장할 수 있습니다. 또한 매핑할 프로퍼티의 불일치 등을 걱정할 필요가 없습니다. 빌드를 통해 생성된 QClass를 통해서 데이터를 매핑하기 때문입니다. 

 

 

MyBatis 타입 안정성에 대한 생각

MyBatis는 어노테이션과 XML을 통해 쿼리를 작성하고 메서드를 통해 특정 타입의 객체를 반환하도록 할 수 있습니다. 하지만 XML로 작성을 하게 되면 정의한 resultType과 @Mapper 인터페이스의 메서드 반환형과의 타입이 일치하지 않는 문제가 있어 런타임 에러를 발생시킬 수 있습니다. 어노테이션만을 고집하여 쿼리를 작성한다면 XML보다 런타임 에러 발생 확률이 적을 수 있겠으나, 개발자가 작성한 쿼리의 결과 컬럼과 매핑할 클래스의 프로퍼티가 일치하지 않아 런타임 에러가 발생할 가능성도 있으므로 MyBatis는 타입 안정성이 떨어진다고 생각을 합니다.

 

 

JdbcTemplate  타입 안정성에 대한 생각

JdbcTemplate으로 Select 쿼리를 작성하게 되면 RowMapper에서 ResultSet을 이용하여 엔티티 클래스에 매핑로직을 작성하여 처리할 수 있습니다. 매핑 로직을 자바 코드로 작성을 하게 되면 컴파일에 의해 예외 감지가 되기 때문에 타입 안정성이 어느 정도 있다고 생각이 됩니다. 하지만 이 역시 반환형을 잘못 주거나 (예, queryForObject 메서드) , 조회 쿼리의 반환 컬럼들과 엔티티 클래스의 프로퍼티가 정확히 일치하지 않는다면 매핑 시 예외가 발생할 수 있어서 타입 안정성에 대한 위험이 있습니다.

 

 

 

타입 안정성을 위해서라면 QueryDSL을 사용하는 것이 권장됩니다. 하지만 필요에 의해 JdbcTemplate이나 MyBatis를 사용하게 되는 경우가 발생하는데요. 이 때는 개발자 본인이 타입 안정성을 신경써서 개발을 진행해야 합니다.

 

 

---

 

 

Reference URIs

http://querydsl.com/static/querydsl/4.0.1/reference/ko-KR/html_single/

GPT