[Spring]JDBC(Java DataBase Connectivity)

Spring MVC - Controller + Service

[Spring]Spring MVC

[Spring]Spring MVC - Controller 클래스 구조 생성 및 설계

[Spring]Spring MVC - Controller 클래스에 핸들러 메서드(Handler Method) 구현

[Spring]Spring MVC - Controller 클래스에 ResponseEntity 적용

[Spring]Spring MVC - Controller 클래스에 DTO 적용

[Spring]Spring MVC - DTO 유효성 검증(Validation)

[Spring]Spring MVC - DI를 통한 API 계층 ↔ 서비스 계층 연동

[Spring]Spring MVC - 매퍼(Mapper)를 이용한 DTO 클래스 ↔ 엔티티(Entity) 클래스 매핑

[Spring]Spring MVC - @ExceptionHandler를 이용한 예외처리

[Spring]Spring MVC - @RestControllerAdvice를 이용한 예외처리

[Spring]Spring MVC - 비즈니스로직 예외 던지기(throw) 및 처리

[Spring]Spring MVC - Custom Exception을 이용한 클라이언트 출력

 

Spring Data JDBC

[Spring]JDBC(Java DataBase Connectivity)

[Spring]SQL Mapper vs. ORM

[Spring]Spring Data JDBC, Spring Data JDBC 사용법

[Spring]Spring Data JDBC - 도메인 엔티티&테이블 설계

[Spring]Spring Data JDBC - 도메인 엔티티 클래스 정의

[Spring]Spring Data JDBC - Service, Repository 구현

 

Spring Data JPA

[Spring]JPA(Java Persistence API)

[Spring]JPA - Entity ↔ DB Table Mapping

[Spring]JPA - Entity ↔ Entity Mapping

[Spring]Spring Data JPA - 데이터 액세스 계층 구현

[Spring]ORM, Hibernate, JPA, Spring Data JPA

[Spring]트랜잭션(Transaction)

[Spring]트랜잭션(Transaction) - @Transactional

 

지난 글까지 웹 앱 서비스 계층의 구현을 마쳤다.

 

이번 글부터는 더 깊이 들어가 데이터 액세스 계층에 대해 다룰 텐데,

 

다시 짧게 복습하고 가자.

 

• Presentation Layer - API Layer라고 불리며 클라이언트의 요청을 받아들이는 계층이다. GUI, 웹 화면 등을 포함한다.
• Application Layer - Service Layer, Business Layer, 혹은 WAS(Web Application Server)라고도 불린다. Presentation Layer에서 수집된 유저의 요청(기능의 사용)이 업무 도메인(범위, 과정)의 요구사항에 맞게 처리되며, 이 과정에서 비즈니스 로직이 사용된다.  또한 Data Access Layer의 데이터를 추가, 삭제, 수정할 수 있다.
• Data Access Layer - DB Server라고도 불리며 앱의 데이터베이스에 접근하여 데이터를 불러오거나 저장을 담당한다. Application Layer에서 유저의 요청을 처리할 때 이에 대한 작업을 지원한다. 이 단계를 통해 Application Layer의 비즈니스 로직은 데이터베이스에 접근해서 데이터를 회수하고 저장하는 방식을 최적화할 수 있다.

2022.08.10 - [개발/Spring] - [Spring]아키텍처

[Spring]아키텍처

위에도 쓰여있지만 데이터 액세스 계층은 간단하게 말해 비즈니스 로직을 거쳐 데이터를 저장하고 불러오는 역할을 한다.

 

조금 더 구체적으로는 비즈니스 로직이 처리할 데이터를 불러오고, 로직이 처리한 데이터를 저장하는 작업을 수행한다.

 

데이터 액세스 계층을 더 세분화하면 아래 그림과 같이 되는데,

 

출처: https://herbertograca.com/2017/08/03/layered-architecture/

Layered Architecture

계층 사이에 전달되는 실질적 비즈니스 객체인 도메인 모델을 다루는 계층과

 

데이터베이스 접근과 CRUD 연산을 수행하는 영속성 계층으로 나눈 것을 확인할 수 있다.

 

여기서 영속성이란 단어 그대로 앱이 종료되어도 저장된 데이터는 남는다는 뜻이며,

 

이를 보장해주는 프레임워크를 Persistence Framework라 부르기도 한다.

 

이 글에서 알아볼 JDBC는 바로 이 영속성(Persistence)을 보장하기 위해 자바에서 지원하는 기능이며

 

때문에 이후에 알아볼 JDBC 기반의 기술들은 전부 영속성 계층에 속한다고 볼 수 있다.

 

즉, 이제부터 알아볼 영역은 엄밀하게 말하면 영속성 계층이라는 뜻이다.

 

이어서 스프링 프레임워크의 모듈 구조를 보면, 이제부터 다룰 내용이 조금 더 명확해진다.

 

출처: https://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/html/overview.html

2. Introduction to Spring Framework

모듈 구조의 데이터 액세스 영역에 보면 JDBC, ORM 등의 용어가 보인다.

 

당연하게도 데이터베이스에 접근하기 위해 지원하는 기술들의 이름을 나타내는데, 이 글에서 알아볼 것은 JDBC이다.

 

간략하게 알아보자.

 

 

JDBC(Java DataBase Connectivity)

 

JDBC는 한 마디로 말하자면 자바의 데이터베이스 커넥터이다.

 

정의대로 앱에서 데이터베이스에 액세스 해 코드 레벨 데이터를 추가, 수정 혹은 DB의 데이터를 불러오는 기능을 제공한다.

 

기존의 벤더(Oracle, MySQL 등)는 독자적인 DB Driver를 가지고 있었고 개발자는 각 문법에 따라 쿼리문을 적어야 했다.

 

JDBC는 DB Driver*들의 작성 방식을 통일시켜 API로 표준화(명세) 했는데, 

 

*Driver - 데이터베이스와의 통신을 담당하는 인터페이스

 

이는 JDBC를 사용하고 있다면, Oracle에서 MySQL로 DB를 변경해도 DB Driver에 따라 새로 작성할 필요가 없게 만들었다.

 

또한 다양한 DB들의 연결을 위한 표준이기 때문에 JDBC는 대부분이 인터페이스로 이루어져 있다.

 

추가로 자바의 모든 데이터 액세스는 내부적으로 JDBC API를 사용하고 있기 때문에,

 

실제로 직접 사용할 일이 없다고 하더라도 JDBC의 WorkFlow를 알아놓는 것은 도움이 된다.

 

그럼 실제로 동작하는 방식과 순서에 대해 알아보자.

 

 

• JDBC Workflow

위에도 그림을 첨부했지만, 단순하게 보면 JDBC는 다음과 같이 동작한다.

 

JDBC API를 사용하기 위해서 JDBC Driver를 거쳐야 하는 것을 확인할 수 있다.

 

정확하게는 인터페이스로 이루어져있는 JDBC API를 클래스로 구현하는 것이 JDBC Driver Manager이다.

 

 

• JDBC 개발 절차

JDBC는 정해진 순서에 따라 개발해야 하며 전반적인 순서는 아래와 같다.

 

순서에 따라 간단하게 살펴보자.

 

0. JDBC 패키지 Import
1. JDBC Driver 로딩 - DriverManager 클래스를 통해 로딩
2. DB 연결 - DriverManager를 통해 DB와 연결되는 세션, Connection 객체 생성
3. Statement 객체 생성 - 작성된 쿼리문을 실행하기 위한 객체. 정적인 SQL 쿼리를 입력으로 가짐
4. SQL문 전송 - Statement 객체를 이용해서 SQL 쿼리 실행
5. 결과받기 및 처리 - 실행된 SQL 쿼리문에 대한 결과 데이터 셋을 받고 처리함
6. 연결 해제 - 역순으로 객체 닫기

그런데 매번 사용자가 요청을 할 때마다 위와 같이 Connection 객체를 생성하고 종료하면 비용이 많이 소모된다.

 

기업용 프로그램처럼 수많은 사람들이 한 번에 이용한다면 성능에도 크게 문제가 생길 것이다.

 

이런 문제를 해결하기 위해 사용되는 것이 바로 커넥션 풀(DBCP - DataBase Connection Pool)이다.

 

• Connection Pool

Connection Pool은 이름 그대로 커넥션 객체를 관리하는 역할을 한다.

 

조금 구체적으로는 Connection을 미리 만들어 보관하고 필요할 때 제공해주는 역할을 하는 관리자가 Connection Pool이다.

 

주요 역할을 요약하면 아래와 같다.

 

• 앱 로딩 시점에 Connection 객체를 미리 Pool에 생성 - 요청마다 연결 시간이 소비되지 않는다.
• HTTP 요청에 따라 Pool에서 Connection객체를 가져다 쓰고 반환
• 물리적인 데이터베이스 Connection 부하를 줄이고 연결을 관리
• 커넥션을 재사용하기 때문에 생성되는 커넥션 수를 제한

커넥션 풀에는 Commons DBCP와 Tomcat-JDBC, BoneCP, HikariCP 등이 있으며,

 

스프링 부트 2.0부터는 압도적인 성능을 가지고 있는 HikariCP를 기본 DBCP로 채택하고 있다.

 

참고로 커넥션 풀의 벤치마크 결과는 아래와 같다.

 

출처: https://github.com/brettwooldridge/HikariCP

GitHub - brettwooldridge/HikariCP: 光 HikariCP・A solid, high-performance, JDBC connection pool at last.

 

• JDBC의 단점

지금까지 알아본 JDBC에는 단점이 있는데, 데이터베이스 연결과 SQL 사용, 결과값의 Data Type 매핑 등

 

모든 과정을 개발자가 직접 입력해주어야 한다는 점이 그것이다.

 

위 그림에서 알아본 각 단계를 일일히 구현해주어야 한다는 의미이다.

 

이를 해결하기 위한 여러 방법들이 있는데, 다음 글부터 알아보기로 하자.