들어가며
- 저번 포스트에서 JDBC가 등장하게 된 계기와 효율성, 그리고 그 한계점에 대해 알아보았다.
- 이번 포스트에서는 JDBC를 활용하여 DB에 접근하는 기술들, 특히 SQL Mapper와 ORM에 대해 알아보도록 한다.
JDBC 직접 사용과 SQL Mapper
- JDBC가 나온지 얼마 안된 초창기에는 대부분 JDBC에 다이랙트로 접근하여 SQL을 전송하는 방식을 사용하였다.
- 하지만 이는 너무 오래 전의 기술로 현재는 대부분 사용하지 않는 방식이다. 현재 사용하는 기술은 SQL Mapper가 있다.
SQL Mapper
- 기존에 JDBC를 다이랙트로 사용하던 때에는 DB에서 데이터를 가져올 때 일일히 객체에 매핑했었어야 했다.
@AllArgsConstructor
public class Member{
private long id;
private String username;
private int age;
private String gender;
}
- 이런 회원 객체가 존재한다고 가정하자. 이 회원 객체는 Java 코드에서 회원의 상태(데이터)를 표현한다. DB에서 결과를 반환할 때 이런 객체로 곧바로 주지 않기 때문에 DB에서 응답을 받은 뒤, new Member() 등의 생성자를 통해 일일히 매핑해주어야 하는 과정이 수반되어야 했다.
- 또한 이후에 JDBC를 직접 사용하는 포스트에서 보게 되지만 중복되는 코드들이 매우 많다.
- 이를 해결하기 위해 나온 것이 SQL Mapper로 JdbcTemplate이나, MyBatis가 SQL Mapper기술을 활용한 것들이다. SQL Mapper는 위의 문제점들을 해결해주고 여러 편의 기능도 제공해준다.
- 또한 SQL을 사용할 줄 알면 곧바로 적용이 가능한 기술이기 때문에 금방 배워 적용할 수 있다.
- 해당 기술의 한계점은 이전에 보았던 JDBC의 한계점과도 유사하다. SQL을 결국 개발자가 직접 작성해야 하고, SQL이 DB마다 다른 문법을 가지고 있기 때문에 변경이 일어난다면 SQL 역시 모두 변경되어야 한다.
ORM 기술
- ORM 기술은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 즉 위의 Member와 같은 객체를 DB에 존재하는 회원 테이블과 매핑해주는 기술이라고 할 수 있다.
- 이 기술을 활용하면 개발자는 SQL를 직접 작성하지 않아도 된다. ORM이 개발자 대신 연산에 대한 SQL을 동적으로 생성하여 JDBC로 넘겨준다.
- 해당 기술의 강력함은 SQL Mapper가 해결하지 못했던 DB변경이 일어날 시 SQL이 모두 변경되어야 한다는 한계점을 해결한 것에서 알 수 있다.
- 즉 ORM 기술을 구현한 구현체에서 어떤 DB를 사용하는지에 따라 해당 DB에 맞는 SQL을 동적으로 작성해주는 것이다.
- 해당 기술을 구현한 것들은 JPA, Hibernate 등이 있다. JPA는 자바의 ORM 표준 인터페이스고 해당 인터페이스를 구현한 구현체가 Hibernate나 EclipseLink가 있다.
- 문제는 ORM 기술이 SQL을 동적으로 짜주고, 객체를 테이블과 매핑하는, 일종의 추상화를 한 번 더한 느낌으로 진행되기 때문에 깊이있는 학습이 요구된다.
- 또한 SQL을 동적으로 짜주는 것이 문제점이 될 수 있는데, 개발자가 기대하던 SQL과 다른 SQL 구문이 작성될 수 있으며 개발자가 직접 SQL를 작성하는 것이 아니기 때문에 성능 개선을 수행해야 할 때도 생각할 것들이 많아질 수 있다.