JDBC, SQL Mapper(MyBatis), ORM

해당 포스팅은 테코톡 유튜브를 기반으로 작성되었습니다.
https://www.youtube.com/watch?v=VTqqZSuSdOk
https://www.youtube.com/watch?v=mezbxKGu68Y

---

JDBC, SQLMAPPER, ORM의 공통점

PERSISTENCE 영속성

데이터를 생성한 프로그램의 실행이 종료되더라도

사라지지 않는 데이터의 특성

영구히 저장되는 그 어떤 것

 

JDBC

JAVA DATABASE CONNECTIVITY

 

1997년 JDBC의 등장

JDBC API (JAVA DATABASE CONNECTIVITY)

1990년대 중반, 인터넷이 보급되고 DB산업이 성장했습니다.

그에따른 온라인 비지니스의 투자 증가로 DB Connector에 대한 니즈가 생깁니다.

 

JAVA 진영의 Database 연결 표준 인터페이스

자바 애플리케이션에서 DBMS의 종류에 상관 없이,

하나의 JDBC API를 이용해  DB작업을 처리하는 것입니다.

각각의 DBMS는 이를 구현한 JDBC 드라이버를 제공합니다.

드라이버 매니저만 변경하면 어떤 제품이든 접근가능하도록 만들어진것이

JDBC API입니다.

 

JDBC API 사용과정

 

어떤점이 불편하였는가?

1. 간단한 SQL을 실행하는 데도 중복된 코드가 너무 많았다.

2. DB에 따라 일관성 없는 정보를 가진 채로 Checked Exception(SQLException) 처리

3. Connection과 같은 공유 자원을 제대로 릴리즈(반환) 해주지 않으면 시스템의 자원이 바닥나는 버그 발생

3. 쿼리를 일일히 작성하여야 합니다.

4. 커넥션 관리를 계속 해주어야 합니다.

 

이런 불편함 때문에 JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로

데이터베이스와 연동되는 시스템을 빠르게 개발하게 되었습니다.

이것을 Persistence Framework 라고 합니다.

 

모든 Persistence Framework는 내부적으로 JDBC API를 이용하는데

이를 SQL Mapper와 ORM으로 나눌 수 있습니다.

 

---

SQL Mapper

SQL을 직접 작성

여기서 주의해야할 점은 객체와 관계를 매핑하는것이 아니라

직접 작성한 SQL 문의 질의 결과와 객체(Obejct)의 필드를 매핑하여 데이터를 객체화하는 것입니다.

 

Spring JDBC

SQL Mapper - JDBC만 사용했을 때

JDBC Template

.JDBC Template을 사용함으로써 우리는

쿼리 수행 결과와 객체의 필드를 맵핑하고 RowMapper를 재활용 할 수 있습니다.

JDBC에서 반복적으로 해야하는 많은 작업들을 대신 해줍니다.

 

 

커넥션을 위한 설정들을 DataSource를 통하여 주입시켜주고

JDBC 템플릿을 통하여 데이터를 꺼내옵니다.

 

 

---

 

MyBatis 

반복적인 JDBC 프로그래밍을 단순화 시켜줍니다

SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL을 분리하여 관리되도록 합니다.

 

순수 JDBC만 사용하면 결과를 가져와서 객체의 인스턴스에 매핑하기 위한 많은 코드가 필요하겠지만

마이바티스는 그 코드들을 작성하지 않아도 되도록 해줍니다.

 

SQL을 분리하자!

 

 

Query를 JAVA에서 XML로

• 복잡한 JDBC 코드가 사라집니다.
• ResultSet과 같이 결과값을 맵핑하는 객체가 없습니다.
• 설정이 간단합니다.
• 관심사를 분리합니다.

결국 SQL을 JAVA의 메소드에 매핑해줍니다.

 

 

MyBatis Data Access 순서

Spring Boot에서 MyBatis를 사용할 경우 DB에 접근하기 위해

별다른 작업이 필요없이 Mapper인터페이스와 맵핑파일만 구현하면 자연스럽게

객체의 필드와 SQL문이 맵핑됩니다.

Mapper인터페이스에 대한 구현체는 개발자가 직접 구현하지 않아도

MyBatis에서 자동으로 생성하게 됩니다.

 

MyBatis를 이용한 객체에대한 DB처리 일부과정

namespace = 매핑할 인터페이스의 경로

id = 매핑할 메서드 명

parameterType = 파라미터 타입

resultType = 반환 값의 타입

 

 

MyBatis Dynamic SQL (동적쿼리)

MyBatis는 상황에 따라 분기처리를 통해 쿼리를 동적으로 만들어주는

동적쿼리를 지원합니다.

 

MyBatis 장점

1. 자동으로 Connection 관리를 해주면서 JDBC 사용할 때의 중복 작업 대부분을 없애준다.

2. 복잡한 쿼리나 다이나믹하게 변경되는 쿼리 작성이 쉽다.

3. 관심사 분리 - DAO로부터 SQL문을 분리하여 코드의 간결성 및 유지보수성이 향상된다.

 

JAVA단 에서는 쿼리문을 모르지만 SQL을 사용가능 합니다.

 

많은 불편함이 MyBatis등의 Persistence 프레임워크인 SQL Mapper를 통해

많은 편리함을 느낄 수 있었지만 아직 해소되지 못한 불편한점이 있습니다.

 

 

SQL을 직접 다룸으로 생기는 문제점

1. 특정 DB에 종속적으로 사용하기 쉽다.

2. 테이블 마다 비슷한 CRUD SQL = DAO 개발이 매우 반복되는 작업

3. 테이블 필드가 변경될 시 이와 관련된 모든 DAO의 SQL문, 객체의 필드 등을 수정해야 한다.

   = 코드상으로 SQL과 JDBC API를 분리했다 하더라도 논리적으로 강한 의존성을 가지고 있다.

 

또한, 직접 SQL문을 작성하면 SQL에 의존적으로 개발하게 됩니다.

즉, 객체와의 관계는 사라지고 DB에대한 처리에 집중하게 됩니다

 

 

관계형 DB와 객체간의 패러다임 불일치

객체지향으로 설계된것을 관계형 DB에 저장하기란 어렵습니다.

또한, 테이블에 저장한 데이터를 다시 객체화 하는데에도 어려움이 생깁니다.

 

---

ORM

OBJECT - RELATIONAL MAPPING

객체와 관계형 DB를 맵핑

SQL Query가 아닌 직관적인 코드(메서드)로 데이터 조작

ex) SELECT * FROM user; -> user.findAll();

 

JAVA는 객체지향적으로 구현되어 있는데,

관계형 데이터베이스에 이를 엮자니 너무 어려웠습니다.

 

예를들면 객체안의 객체의 경우 표현할 수 없습니다. private Team

물리적으로 SQL과 JDBC API를 데이터 접근 계층에 숨기는 데

성공했을지는 몰라도, 논리적으로는 엔티티와 아주 강한 의존 관계를 가지고 있습니다.

한쪽에서 변경이 일어나면 다른 한쪽에서도 변경이 생기게됩니다.

패러다임의 불일치(연관 관계[객체참조], 상속)

 

점점 SQL 의존적인 개발을 개발을 하게되어 객체지향을 사용하지 않아서

ORM이 등장하게 됩니다.

 

JPA

JPA는 ORM의 대표적인 예로 JAVA ORM에 대한 API 표준 명세입니다.

인터페이스로 구성되어 있으며 사용하려면 ORM 프레임워크를 사용하여야 합니다.

JPA에는 HIBERNATE, EclipseLink, DataNucleus라는 구현체가 있습니다.

여기서 가장 대표적인 프레임워크가 하이버네이트 입니다.

---

패러다임 불일치 - 상속

RDB의 테이블은 객체의 상속이라는 개념이 없습니다.

 

만약 좀 더 복잡한 상속관계에 있다면 쿼리문 또한 점점 늘어나고 복잡하게 만들어집니다.

 

이러한 패러다임 불일치 문제는 JPA를 통해 손쉽게 해결가능 합니다.

 

---

 

패러다임 불일치 - 연관관계

객체는 참조를 사용해 다른 객체와 연관관계를 가집니다.

테이블은 외래키를 사용해 다른 테이블과 연관관계를 가집니다.

 

이런 차이를 해결하기 위해 만약 객체를 테이블 연관관계에 맞추어 모델링을 하게된다면

저장하거나 조회할때는 편리함을 느끼겠지만

객체지향의 특징을 버리게됩니다.

 

객체지향적으로 모델링을 한다면

객체간의 연관성에 대한 문제는 해결되지만,

테이블 기준으로 본다면 저장하거나 조회하는것이 복잡해지게 됩니다.

 

이러한 연관관계 문제 또한 JPA를 사용하여

손쉽게 해결이 가능합니다.

---

패러다임 불일치 - 객체 그래프 탐색

객체에서 Crew가 소속된 팀을 조회할때는 다음처럼 참조를 사용하여

연관된 팀을 찾으면 되는데 이것을 객체 그래프 탐색이라고 합니다.

객체내에서는 그래프 탐색을 자유롭게 할 수 있지만

SQL을 다룰 때는 작성하는 쿼리에따라 객체의 그래프 탐색의 범위가 제한됩니다.

 

이러한 문제도 JPA로 해결이 가능합니다.

JPA가 제공하는 메서드를 사용하면 적절한 조회쿼리를 알아서 사용해줍니다.

---

패러다임 불일치 - 비교

DB는 기본 키의 값으로 각 row를 구분

객체는 동일성 비교와 동등성 비교로 구분

이 둘의 조회결과는 false가 나오게 됩니다.

DB에서 둘은 같은 데이터이지만

객체의 측면에서 볼때는 둘은 다른 인스턴스이기 때문입니다.

 

하지만, JPA는 같은 트랜잭션일 때 같은 객체가 조회되는것을 보장합니다.

---

ORM의 장단점

 

 

ORM을 사용해야하는 이유

ORM을 사용함으로써..