Sql Mapper (mybatis) 의 단점 요약 !

 

Sql Mapper 는 java 와 xml 이 완전히 분리되어 있어 JDBC 를 사용하는 것에 비해 편리하다.
하지만 Sql Mapper 프레임워크도 단점이 존재한다. 그 단점에 대해 알아보려 한다.

 

 

반복되는 코드와 SQL

SQL 을 직접 사용하므로 테이블이 많아지면 Value 클래스가 많이 필요하다.

또한 테이블이 많아질수록 SELECT, INSERT, UPDATE, DELETE 기본 쿼리도 테이블 개수만큼 작성해야 한다.

SELECT 구문이 복잡해지거나 조인 쿼리를 사용할 때마다 객체 클래스 들이 더 필요하게 되다.

이와 비례하여 XML Mapper 에 쿼리 결과와 값 객체 클래스의 속성을 매핑하는 구문이 추가된다.

DAO 클래스의 메서드가 늘어나면 메서드 개수에 비례하여 SQL 코드양이 증가한다.

결국 반복되는 SQL 쿼리가 많아지고 그에 따라 전체적인 코드양도 증가한다.

관계형 데이터베이스에 의존하는 애플리케이션

관계형 데이터베이스마다 SQL 문법이 다르고, 사용할 수 있는 함수도 다르다.

SQL Mapper 프레임워크는 개발자가 SQL 을 직접 사용해야하는데 데이터베이스에 적합한 SQL 구문을 사용햐여 한다.

개발 도중 데이터베이스가 변경되면 Mapper.xml 에 정의된 모든 SQL 문을 확인하고 수정해야 한다.

그러므로 한번 개발된 애플리케이션의 데이터베이스는 변경하기 매우 어렵다.

애플리케이션을 유연하게 수정하기 힘듦

테이블의 필드 이름이 바뀌거나 추가되면 관련된 쿼리를 모두 확인해야한다.

또한 데이터를 저장하는 클래스도 수정해야 한다.

즉 SQL 구문과 클래스가 강하게 결합되어있으므로 유연하게 프로그래밍하기 어렵다.

객체 구조와 관계형 데이터베이스의 테이블 구조가 다름

객체지향 프로그래밍에서의 객체와 객체가 관게를 맺는 방식은 관계형 데이터베이스의 테이블들이 관계를 맺는 방식과는 다르다.

객체는 다른 객체를 포함하거나 상속하는 구조지만, 테이블은 다른 테이블과 조인하는 방식으로 관계를 맺는다.

두 테이블의 값은 조회할 수 있지만 상속이나 포함하는 구조를 갖기는 쉽지 않다.

또한 다른 객체를 포함하는 객체 합성도 데이터베이스에서 표현하기 어렵다.

이를 보통 '패러다임의 불일치' 라고 한다.

이처럼 객체와 레코드의 데이터 연관 구조가 다르므로 객체지향 프로그래밍에 적합하지 않다.

SQL 중심의 코드 구조와 비즈니스 로직

쿼리를 직접 사용해야 하는 SQL Mapper 프레임워크 환경에서는 코드 베이스에 SQL 구문이 반드시 필요하다.

그래서 코드베이스에는 쿼리 비중이 높다.

그러므로 자바 코드는 쿼리구문을 실행하는데 집중하게되고, 비지니스 로직이 데이터베이스에도 포함된다.

즉, 애플리케이션의 핵심로직이 애플리케이션과 데이터베이스 양쪽에 분산될 수 있다.

결국 데이터베이스에 의존하는 애플리케이션은 서비스를 확장할 때 데이터베이스에 더 많은 부하나 장애가 집중되는 단일 장애 지점이 된다.