Spring은 트랜잭션 관리를 위한 간단하고 강력한 기능을 제공합니다. 주로 @Transactional 어노테이션을 사용합니다.
a. 기본 사용법
@Service
public class BankService {
private final AccountRepository accountRepository;
public BankService(AccountRepository accountRepository) {
this.accountRepository = accountRepository;
}
@Transactional
public void transferMoney(Long fromAccountId, Long toAccountId, int amount) {
Account fromAccount = accountRepository.findById(fromAccountId).orElseThrow();
Account toAccount = accountRepository.findById(toAccountId).orElseThrow();
fromAccount.withdraw(amount); // 출금
toAccount.deposit(amount); // 입금
accountRepository.save(fromAccount);
accountRepository.save(toAccount);
}
}
@Transactional:
메서드 내의 모든 작업이 하나의 트랜잭션으로 처리.
하나라도 실패하면 Rollback.
Rollback 처리
Spring에서 특정 예외 발생 시 트랜잭션을 Rollback합니다.
예외 처리 예제
@Transactional(rollbackFor = CustomException.class)
public void processTransaction() throws CustomException {
// 작업 실행
if (errorCondition) {
throw new CustomException("Error occurred");
}
// 다른 작업 실행
}
rollbackFor: 특정 예외 발생 시 Rollback 설정.
기본적으로 RuntimeException이나 Error가 발생하면 Rollback.
관계형 데이터베이스 ( RDB )
📌 데이터를 테이블(Table) 형태로 저장하고, 관계(Relationship)를 통해 데이터를 연결하여 관리하는 데이터베이스입니다. 관계형 모델을 기반으로 설계되었으며, 데이터를 행(Row)과 열(Column)의 구조로 저장합니다.
RDB는 주로 **SQL(Structured Query Language)**을 사용하여 데이터를 정의, 관리, 검색합니다.
RDB 설계 시 주요 개념
a. 정규화(Normalization)
데이터 중복을 최소화하고 데이터 구조를 최적화.
b. 비정규화(Denormalization)
성능 향상을 위해 일부 데이터 중복 허용.
c. 키(Key)
Primary Key: 테이블의 각 행을 고유하게 식별.
Foreign Key: 다른 테이블의 Primary Key를 참조.
d. 인덱스(Index)
데이터 검색 속도를 향상시키는 구조.
e. 뷰(View)
실제 데이터 없이 쿼리 결과를 저장하는 가상 테이블.
RDBMS와의 관계
**RDB(Relational Database)**는 관계형 데이터 모델을 기반으로 설계된 데이터베이스이며, 이를 관리하는 소프트웨어를 **RDBMS(Relational Database Management System)**라고 합니다.
RDB
관계형 데이터 모델에 따라 설계된 데이터베이스.
RDBMS
RDB를 생성, 관리, 유지보수하는 소프트웨어 시스템.
SQL
RDB와 RDBMS에서 데이터를 처리하기 위해 사용하는 언어.
RDB의 데이터 모델
a. 1:1 관계
한 테이블의 행이 다른 테이블의 행과 1:1로 매핑.
예: 사람(Person) ↔ 여권(Passport)
b. 1:N 관계
한 테이블의 행이 다른 테이블의 여러 행과 매핑.
예: 사용자(User) ↔ 주문(Order)
c. N:M 관계
두 테이블의 여러 행이 서로 다수의 행과 매핑.
예: 학생(Student) ↔ 수업(Class)
+ 해결 방법: 중간 테이블(Join Table) 사용.
학생(Student) ↔ 수강 기록(Student_Class) ↔ 수업(Class)
관계형 데이터베이스 특징
테이블 (Table)
RDBMS에서 데이터는 테이블이라는 구조에 저장되며 행(row)과 열(column)로 구성된다.
열(column)은 데이터의 속성(유일한 이름)을 나타내고 타입(데이터 유형)을 가진다.
행(row)은 관계된 데이터의 묶음을 의미하고 tuple 또는 record라고 한다.
데이터 무결성
테이블은 특정 규칙과 제약 조건(기본 키, 외래 키, 유니크 등)을 통해 데이터를 저장함으로써 데이터의 무결성(정확성, 일관성, 유효성)을 유지한다.
관계 (Relationships)
테이블 간의 관계는 외래 키(Foreign Key)를 통해 설정된다.
RDBMS는 다양한 유형의 관계를 지원한다.
1:1 관계: 한 테이블의 한 행이 다른 테이블의 한 행과만 연결된다.
1:다 관계: 한 테이블의 한 행이 다른 테이블의 여러 행과 연결된다.(위 예시와 같음)
다:다 관계: 두 테이블의 여러 행이 서로 연결될 수 있다.
SQL (Structured Query Language)
RDBMS에서 데이터를 정의하고, 관리하기 위한 표준 언어이다.
데이터를 생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)하는 작업을 수행한다.
키 (Keys)
기본 키(Primary Key)
테이블 내에서 각 행을 고유하게 식별하는 열 또는 열의 조합이다.
기본 키는 중복되지 않으며, NULL 값을 가질 수 없다.
외래 키(Foreign Key)
한 테이블의 열이 다른 테이블의 기본 키를 참조하여 두 테이블 간의 관계를 설정하는 데 사용된다.
테이블 간의 데이터 무결성을 유지할 수 있다.
유일 키(Unique Key)
기본 키와 유사하지만, 하나의 테이블에서 여러 개가 존재할 수 있다.
중복된 값을 허용하지 않지만, NULL 값은 허용할 수 있다.
트랜잭션(Transaction)
RDBMS는 트랜잭션이라는 단위를 통해 데이터베이스 작업을 처리하며, 이를 통해 데이터의 일관성과 무결성을 유지한다.
트랜잭션은 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)이라는 ACID 속성을 따른다.
Atomicity: 트랜잭션의 모든 작업이 성공적으로 완료되거나, 실패 시 모든 작업이 롤백
Consistency: 트랜잭션이 데이터베이스를 일관된 상태로 유지
Isolation: 동시에 실행되는 트랜잭션 간의 영향을 최소화
Durability: 트랜잭션이 완료된 후 데이터의 변경 사항은 영구적으로 저장
정규화 (Normalization)
데이터의 중복을 줄이고, 일관성과 무결성을 유지하기 위해 데이터를 구조화하는 프로세스이다.
여러가지 정규화 단계가 있으며, 각 단계는 데이터 중복을 줄이고 이상 현상을 방지하는 데 목적이 있다.
데이터 무결성 (Data Integrity)
엔터티 무결성
각 테이블의 기본 키(PK)가 중복되지 않고 NULL 값이 아닌 상태를 유지한다.
참조 무결성
외래 키(FK)를 통해 참조되는 데이터가 유효성을 유지하도록 보장한다.
도메인 무결성
각 열이 정의된 데이터 타입과 제약 조건에 따라 유효한 값을 유지하도록 한다.
인덱스 (Index)
특정 열의 검색 성능을 향상시키기 위해 사용된다.
인덱스는 테이블의 데이터를 정렬하고, 효율적으로 접근할 수 있도록 지원한다.
인덱스가 많아지면 삽입 및 수정 작업의 성능에 영향을 미칠 수 있다.
RDBMS
📌 관계형 데이터베이스 RDB(Relational DataBase)를 관리할 수 있는 소프트웨어로 데이터를 테이블 형식으로 관리한다. RDBMS는 데이터 간의 관계를 정의하고, 이러한 관계를 바탕으로 복잡한 Query를 실행할 수 있는 기능을 제공한다.
RDBMS는 관계형 모델을 기반으로 데이터의 일관성, 무결성, 동시성을 보장합니다.
RDBMS의 특징
테이블 기반:
데이터를 행(Row)과 열(Column)로 구성된 테이블에 저장.
테이블은 데이터베이스 내에서 독립적으로 관리.
SQL 사용:
데이터를 관리하기 위해 SQL(Structured Query Language) 사용.
키(Key)와 관계(Relationship):
기본 키(Primary Key)와 외래 키(Foreign Key)를 통해 데이터 무결성 및 테이블 간 관계를 관리.
데이터 무결성:
데이터가 정확하고 일관되도록 보장.
트랜잭션 지원:
트랜잭션을 통해 작업의 원자성, 일관성, 고립성, 지속성을 보장 (ACID 특성).
RDBMS의 구성 요소
a. 테이블 (Table)
데이터 저장 구조.
행(Row)과 열(Column)로 구성.
각 열은 속성(Attribute), 각 행은 레코드(Record).
b. 열(Column)
테이블의 필드(Field).
데이터의 유형과 속성을 정의.
c. 행(Row)
각 행은 데이터의 한 개체(Entity)를 나타냄.
d. 기본 키 (Primary Key)
테이블의 각 행을 고유하게 식별하는 열.
e. 외래 키 (Foreign Key)
다른 테이블의 기본 키를 참조하여 테이블 간 관계를 정의.
f. 인덱스 (Index)
데이터 검색 속도를 높이기 위해 사용하는 구조.
주요 RDBMS 예시
RDBMS
특징
MySQL
오픈 소스 RDBMS, 높은 성능과 안정성 제공.
PostgreSQL
오픈 소스 RDBMS, 고급 기능과 확장성 제공.
Oracle Database
상용 RDBMS, 대규모 데이터 처리와 강력한 보안 제공.
Microsoft SQL Server
Microsoft에서 제공하는 상용 RDBMS, 윈도우 환경에 최적화.
SQLite
경량형 RDBMS, 모바일 및 임베디드 환경에 적합.
RDBMS와 NoSQL 비교
RDBMS
NoSQL
데이터 구조
테이블 (행과 열)
문서, 키-값, 컬럼, 그래프 등 다양한 형태.
스키마
고정 스키마 필요
스키마 유연.
데이터 관계
기본 키와 외래 키로 관계 정의
관계를 덜 중요시하거나 애플리케이션에서 관리.
확장성
수직 확장에 적합
수평 확장에 적합.
사용 사례
금융, ERP, CRM 등 일관성과 무결성이 중요한 애플리케이션
소셜 네트워크, IoT, 대규모 데이터 처리.
SQL(Structured Query Language)
📌 관계형 데이터베이스 관리 시스템(RDBMS)에서 데이터를 정의, 조작, 제어, 조회하기 위해 사용되는 표준 프로그래밍 언어이다.
SQL 특징
관계형 데이터베이스와의 상호작용을 표준화하고 효율적으로 수행할 수 있게 해준다.
데이터베이스에서 원하는 정보를 추출하고 분석할 수 있게 해준다.
대부분의 RDBMS(MySQL, PostgreSQL, Oracle 등)가 SQL을 지원한다.
주의! 표준 SQL은 존재하지만, 제품마다 조금씩의 차이(함수명)가 존재한다.
SQL 명령문은 대소문자를 구분하지 않고, 대문자로 사용하면 가독성이 향상되어 오타를 방지한다.
테이블에서 각 행(row)을 고유하게 식별하는 하나 이상의 열(column)에 설정되는 제약조건
중복된 데이터가 테이블에 삽입되는 것을 방지한다.
NOT NULL과 UNIQUE 제약 조건의 특징을 모두 가진다.
INDEX로 설정되어 테이블의 데이터를 쉽고 빠르게 찾도록 도와주는 역할을 한다.
추가적인 쓰기 작업과 저장 공간을 활용하여 검색 속도를 향상시키기 위한 자료구조
CREATE TABLE students (
id BIGINT PRIMARY KEY, -- 학생 고유 번호 (자동 증가)
name VARCHAR(50) NOT NULL, -- 이름
email VARCHAR(100) NOT NULL UNIQUE, -- 이메일
PRIMARY KEY (id) -- PRIMARY KEY 설정
);
Foreign Key (외래 키):
한 테이블의 열이 다른 테이블의 PRIMARY KEY(또는 UNIQUE 제약 조건이 적용된 열)를 참조하도록 설정한다.
참조된 테이블의 데이터가 변경되거나 삭제될 때 참조 무결성을 강제할 수 있다.
외래 키 값은 반드시 참조하는 테이블의 기본 키로 존재해야 한다.
부모 테이블의 데이터가 변경되거나 삭제될 때 자식 테이블에 있는 데이터도 자동으로 업데이트되거나 삭제되도록 보장한다.(CASCADE)
외래 키(Foreign Key) 제약 조건과 관련된 변경 사항이 발생할 때 참조하는 레코드에 대한 동작을 자동으로 처리하는 기능
FOREIGN KEY 로 연관된 데이터를 삭제,변경할 수 있다.
CREATE TABLE 테이블이름
(
필드이름 필드타입,
...
FOREIGN KEY(필드이름)
REFERENCES 테이블이름(필드이름) ON DELETE CASCADE
//ON UPDATE CASCADE
);
1. `ON DELETE CASCADE`
- 부모 테이블의 행이 삭제되면, 참조하는 자식 테이블의 관련 행들도 자동으로 삭제한다.
2. `ON UPDATE CASCADE`
- 부모 테이블의 기본 키가 업데이트되면, 참조하는 자식 테이블의 외래 키 값도 자동으로 수정된다.
DEFAULT
해당 필드의 기본 값을 설정한다.
필드 값이 전달되지 않으면, 자동으로 기본 값을 저장한다.
CREATE TABLE 테이블이름
(
필드이름 필드타입 DEFAULT 값
);
Unique Key:
중복되지 않는 고유한 값을 유지.
b. 제약 조건(Constraints)
데이터 무결성을 유지하기 위한 규칙.
AUTO_INCREMENT : 고유번호 자동생성(컬럼의 값이 중복되지 않게 1씩 자동으로 증가)
NOT NULL: NULL 값 불가.
UNIQUE: 중복 값 불가.
CHECK: 특정 조건 만족.
DEFAULT: 기본값 설정.
FOREIGN KEY: 테이블 간 관계 설정.
-- users 테이블 생성
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY, -- 고유번호 자동생성 (Primary Key 포함)
name VARCHAR(100) NOT NULL, -- 이름은 NULL 값 불가
email VARCHAR(100) UNIQUE NOT NULL, -- 이메일은 중복 불가 및 NULL 값 불가
age INT CHECK (age >= 18), -- 나이는 18세 이상이어야 함
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP -- 기본값으로 현재 시간 설정
);
-- orders 테이블 생성
CREATE TABLE orders (
id INT AUTO_INCREMENT PRIMARY KEY, -- 고유번호 자동생성 (Primary Key 포함)
user_id INT NOT NULL, -- 사용자 ID (외래 키)
amount DECIMAL(10, 2) CHECK (amount > 0),-- 금액은 0보다 커야 함
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 주문 날짜 기본값
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE -- users 테이블과 관계 설정, 사용자 삭제 시 주문도 삭제
);
데이터 무결성
데이터의 정확성, 일관성, 완전성을 유지하는 것
정확성: 데이터가 올바르고 오류 없이 저장되는 것을 의미한다.
ex) 숫자로 저장되어야 하는 값이 문자로 저장되지 않도록 하는 것.
일관성: 데이터가 서로 모순되지 않고 조화를 이루는 상태를 유지하는 것을 의미한다.
ex) 외래 키 제약 조건을 통해 두 테이블 간의 관계가 일치하는 것을 보장하는 것.
완전성: 필요한 모든 데이터가 빠짐없이 저장되고 관리되는 것을 의미한다.
ex) 필수 입력 항목이 비어 있지 않도록 하는 것.
즉, 데이터가 입력, 저장, 전송, 처리되는 동안 변경되거나 손상되지 않도록 보장하는 개념
c. JOIN
두개 이상의 테이블을 연결하여 데이터를 검색하는 방법
테이블을 분리하여 데이터 중복을 최소화하고 데이터의 일관성을 유지하기 위해 사용된다.
JOIN 종류
여러 테이블의 데이터를 결합하여 조회.
INNER JOIN
두 테이블에서 공통된 값을 가지고 있는 행만 반환한다.
ON 절의 조건이 일치하는 결과
MySQL에서는 JOIN, INNER JOIN, CROSS JOIN이 모두 같은 의미이다.
교집합
LEFT JOIN
왼쪽 테이블의 모든 행과 오른쪽 테이블의 일치하는 행을 반환한다.
ON 절의 조건 중 첫번째 테이블인 왼쪽(기준)의 데이터를 모두 가져온다.
오른쪽 테이블에 일치하는 데이터가 없으면 NULL로 반환한다.
JOIN을 여러번 사용하는 경우 LEFT JOIN으로 시작했다면 이후 JOIN도 LEFT JOIN으로 해야한다.
부분 집합(왼쪽 테이블)
RIGHT JOIN
오른쪽 테이블의 모든 행과 왼쪽 테이블의 일치하는 행을 반환한다.
ON 절의 조건 중 두번째 테이블인 오른쪽(기준)의 데이터를 모두 가져온다.
왼쪽 테이블에 일치하는 데이터가 없으면 NULL로 반환한다.
부분 집합(오른쪽 테이블)
OUTER JOIN
두 테이블에서 공통된 값을 가지지 않는 행도 포함해서 반환한다.
합집합
LEFT OUTTER JOIN, RIGHT OUTTER JOIN, FULL OUTTER JOIN(잘 사용하지 않음) 이 있다.
대부분의 DB는 FULL OUTTER JOIN을 지원하지 않고 UNION을 사용하도록 한다.
📌 애플리케이션을 세 가지 주요 계층으로 나누어 구조화하는 방법으로 각 계층은 특정한 책임을 갖고 있으며, 계층 간에는 명확한 역할 분담이 이루어져 코드의 재사용성, 유지보수성, 확장성을 높이는 데 도움을 준다.
주요 특징
계층 분리:
시스템을 기능별로 분리하여 모듈화.
책임 분리:
각 계층은 고유한 책임과 역할을 가짐.
상호 의존성:
상위 계층은 하위 계층에만 의존하며, 계층 간의 의존성을 제한.
유지보수 용이:
특정 계층의 변경이 다른 계층에 최소한의 영향을 미침.
Layerd Architecture 개요
기존의 MVC 패턴에서 Controller는 역할이 무수히 많다.
요청에 대한 처리
예외처리
View Template 응답 or Data 응답
비지니스 로직 처리
DB 상호작용
문제점
Controller에서 요청에 대한 모든 처리를 수행한다. 즉, 책임이 너무 많다.
기능 추가, 수정, 삭제 등의 유지보수가 힘들어진다.
코드의 재사용성이 떨어진다. 메서드로 분리하여도 메서드를 호출하는 중복 코드가 발생한다.
Layered Architecture 구조
Presentation Layer
사용자의 요청을 받고 응답하는 역할을 수행한다.
화면을 응답하거나 데이터를 응답하는 API를 정의한다.
Business Layer(Service Layer)
비지니스 로직을 수행한다.
요청을 해석하여 Repository Layer에 전달한다.
일반적으로 하나의 비지니스 로직은 하나의 트랜잭션으로 동작한다.
Data Access Layer(Repository Layer)
데이터베이스와 연동되어 실제 데이터를 관리한다.
용어 설명
DTO(Data Transfer Object)
계층간 데이터 전달을 위해 사용되는 객체이다.
Model
Entity
추후 숙련주차에 배울 JPA와 관련이 있다.
JPA에서는 Entity라는 형태로 데이터를 반환한다.
DAO(Data Access Object)
계층 간 의존성
상위 계층은 하위 계층에만 의존합니다.
계층 간의 의존성을 단방향으로 제한하여 결합도를 낮춥니다.
계층 간 의존성 예시
Presentation → Application → Domain → Data Access
장점
유지보수성:
계층별 역할이 분리되어, 특정 계층의 변경이 다른 계층에 미치는 영향을 최소화.
재사용성:
서비스나 데이터 계층을 다른 애플리케이션에서도 재사용 가능.
테스트 용이성:
계층 단위로 테스트가 가능하여, 단위 테스트와 통합 테스트를 쉽게 수행.
확장성:
특정 계층에 새로운 기능을 추가하거나 변경하기 쉬움.
단점
복잡성 증가:
계층 간의 통신 코드로 인해 초기 개발이 복잡해질 수 있음.
성능 문제:
계층 간 호출이 많아지면 성능 저하 가능.
단순 CRUD에 과한 구조:
작은 애플리케이션에서는 계층형 아키텍처가 불필요한 복잡성을 초래.
계층형 아키텍처를 사용할 때 적합한 경우
복잡한 비즈니스 로직:
다양한 데이터 소스와 복잡한 비즈니스 규칙이 있는 애플리케이션.
협업 프로젝트:
역할 분리가 명확해 팀 간 작업이 효율적.
대규모 애플리케이션:
변경 사항을 쉽게 관리하고, 시스템 확장이 필요한 경우.
Layered Architecture 적용
1. Controller
클라이언트의 요청을 받는 역할을 수행한다.
요청에 대한 처리를 Service Layer에 전달한다.
Service에서 처리 완료된 결과를 클라이언트에 응답한다.
사용하는 Annotation : @Controller, @RestController
2. Service
사용자의 요청 사항을 처리한다.
DB와 상호작용이 필요한 경우, Repository Layer에게 요청한다.
사용하는 Annotation: @Service
3. Repository
DB와 상호작용을 수행한다.
Connection 연결, 해제
CRUD 작업 처리
사용하는 Annotation: @Repository
4. DTO(Data Transfer Object)
계층간 데이터 전달을 위해 사용된다.
요청 데이터를 처리하는 객체는 일반적으로 RequestDto로 명명한다.
응답 데이터를 처리하는 객체는 일반적으로 ResponseDto로 명명한다.
DTO (Data Transfer Object)
📌 애플리케이션에서 계층 간 데이터 전송을 목적으로 사용하는 단순한 객체입니다.
주로 데이터를 전송하기 위한 속성과 Getter/Setter 메서드만 포함하며, 비즈니스 로직을 포함하지 않습니다.
DTO의 주요 역할
데이터 캡슐화:
데이터 구조를 명확히 정의하여 계층 간 데이터 교환을 표준화.
안전한 데이터 전달:
데이터 모델(Entity)과 직접 연관되지 않아, 민감한 데이터 보호 가능.
데이터 변환 및 제한:
클라이언트가 필요로 하는 데이터만 전달하도록 제한.
API 설계에 유용:
RESTful API에서 응답(Response) 또는 요청(Request) 데이터를 정의.
DTO의 구조
DTO는 일반적으로 다음과 같은 형태로 작성됩니다:
속성 필드
Getter/Setter 메서드
(선택적) 생성자, toString(), equals(), hashCode()
public class UserDTO {
private Long id;
private String name;
private String email;
// 기본 생성자
public UserDTO() {}
// 생성자
public UserDTO(Long id, String name, String email) {
this.id = id;
this.name = name;
this.email = email;
}
// Getter와 Setter
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public String getEmail() { return email; }
public void setEmail(String email) { this.email = email; }
}
DTO의 사용 예
a. 요청(Request) DTO
클라이언트가 서버에 데이터를 보낼 때 사용.
Request DTO 예제
public class CreateUserRequest {
private String name;
private String email;
// Getter와 Setter
}
Controller
@RestController
@RequestMapping("/users")
public class UserController {
@PostMapping
public ResponseEntity<String> createUser(@RequestBody CreateUserRequest request) {
// 요청 데이터 처리
return ResponseEntity.ok("User created: " + request.getName());
}
}
public class UserResponse {
private Long id;
private String name;
private String email;
public UserResponse(Long id, String name, String email) {
this.id = id;
this.name = name;
this.email = email;
}
// Getter만 제공
}
Controller
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
// 서비스에서 가져온 데이터
UserResponse response = new UserResponse(id, "John Doe", "john.doe@example.com");
return ResponseEntity.ok(response);
}
}
@Service
public class UserService {
public UserResponse getUserResponse(UserEntity entity) {
return new UserResponse(
entity.getId(),
entity.getName(),
entity.getEmail()
);
}
}
Spring Boot에서 DTO 자동 변환
Spring Boot에서 DTO 변환을 쉽게 하기 위해 ModelMapper 또는 MapStruct와 같은 라이브러리를 사용할 수 있습니다.
import org.modelmapper.ModelMapper;
@Service
public class UserService {
private final ModelMapper modelMapper = new ModelMapper();
public UserDTO convertToDTO(UserEntity entity) {
return modelMapper.map(entity, UserDTO.class);
}
}
DTO의 장점
데이터 보호:
데이터베이스와 직접 연결된 Entity를 노출하지 않아 민감한 데이터 보호.
역할 분리:
Entity와 DTO를 분리하여 비즈니스 로직과 데이터 전송 책임을 명확히 구분.
API 표준화:
클라이언트 요청과 응답 형식을 명확히 정의 가능.
유지보수성 향상:
데이터 전송 형식 변경이 Entity와 독립적으로 이루어짐.
결론
DTO(Data Transfer Object)는 계층 간 데이터를 주고받을 때 사용되는 단순한 객체입니다.
데이터 캡슐화, 보안성 강화, API 설계 표준화 등의 장점으로, 특히 Spring MVC와 RESTful API 설계에서 널리 사용됩니다.
DTO를 활용하여 애플리케이션의 구조를 더 유연하고 유지보수 가능하게 설계할 수 있습니다.
http://localhost:8080/hello/world.html URL로 리소스에 접근이 가능하다.
/static 대신 /public 혹은 /META-INF/resources 도 사용 가능하다.
View Template (동적 리소)
📌 웹 애플리케이션에서 서버가 클라이언트에 응답으로 제공할 HTML 페이지를 동적으로 생성하기 위해 사용하는 템플릿 파일입니다. 데이터를 표시하기 위해 동적인 콘텐츠와 정적인 HTML 구조를 결합하는 데 사용됩니다.
Spring에서는 Thymeleaf, JSP와 같은 템플릿 엔진을 사용해 View Template을 작성할 수 있고, View Template은 서버에서 데이터를 받아 이를 HTML 구조에 맞게 삽입한 후, 최종적으로 클라이언트에게 전송되는 HTML 문서로 변환하여 사용자에게 동적으로 생성된 웹 페이지를 제공한다.
📌 View Template
View Template은 Model을 참고하여 HTML 등이 동적으로 만들어지고 Client에 응답된다.
Spring Boot는 기본적으로 View Template 경로(src/main/resources/templates)를 설정한다.
build.gradle에 Thymeleaf 의존성을 추가하면 ThymeleafViewResolver와 필요한 Spring Bean들이 자동으로 등록된다.
SSR(Server Side Rendering)을 사용할 때 View가 반환된다.
View Template의 역할
정적 HTML과 동적 데이터 결합:
서버에서 HTML 파일에 동적 데이터를 삽입하여 사용자 맞춤 콘텐츠를 생성.
서버 사이드 렌더링 (SSR):
브라우저에 표시될 HTML을 서버에서 렌더링하고 클라이언트로 전송.
UI 레이아웃 관리:
레이아웃, 반복 구조, 조건부 표시 등과 같은 동적 UI 요소를 효율적으로 관리.
Spring MVC에서 View Template
Spring MVC에서는 Model-View-Controller 패턴을 기반으로 View Template 엔진을 사용하여 HTML을 생성합니다.
Spring MVC에서의 동작 흐름
Controller:
클라이언트의 요청을 처리하고, 데이터를 Model 객체에 담아 View로 전달.
View Template:
Model 데이터를 기반으로 HTML을 렌더링.
Client:
완성된 HTML 페이지를 클라이언트로 전송하여 브라우저에 표시.
pring Boot에서 지원하는 View Template 엔진
Thymeleaf
Spring Boot에서 가장 널리 사용되는 템플릿 엔진. 자연스러운 HTML과의 통합 제공.
@ResponseBody 가 없으면 View Resolver가 실행되며 View를 찾고 Rendering한다.
@Controller
public class ViewTemplateController {
@RequestMapping("/response-view")
public String responseView(Model model) {
// key, value
model.addAttribute("data", "sparta");
return "thymeleaf-view";
}
}
@ResponseBody 가 있으면 HTTP Message Body에 return 문자열 값이 입력된다.
Postman
반환 타입이 void인 경우
잘 사용하지 않는다.
@Controller + (@ResponseBody, HttpServletResponse, OutputStream)과 같은 HTTP Message Body를 처리하는 파라미터가 없으면 RequestMapping URL을 참고하여 View Name으로 사용한다.
@Controller
public class ViewTemplateController {
// thymeleaf-view.html 과 Mapping된다.
@RequestMapping("/thymeleaf-view")
public void responseViewV2(Model model) {
model.addAttribute("data", "sparta");
}
}
예시와 같은 경우에는 viewTemplate(viewName)을 RequestMapping URL 주소로 찾는다.
HTTP Message Body
📌 HTTP Message Body는 HTTP 요청(Request) 또는 응답(Response)에서 실제 데이터를 담는 부분입니다.
REST API를 만드는 경우 Server에서 Client로 HTML을 전달하는 방식이 아닌 HTTP Message Body에 직접 Data를 JSON 형식으로 담아 전달한다.
정적 HTML, View Template 또한 HTTP Message Body에 담겨서 전달된다. 현재 설명하는 Response의 경우는 정적 HTML, View Template을 거치지 않고 직접 HTTP Response Message를 만들어 전달하는 경우를 말하는것.
HttpServletResponse 사용
@Controller
public class ResponseBodyController {
@GetMapping("/v1/response-body")
public void responseBodyV1(
HttpServletResponse response
) throws IOException {
response.getWriter().write("data");
}
}
Postman
Response Body에 data 라는 문자열이 입력되어 응답된다.
기존 Servlet을 다룰 때 코드와 형태가 같다.
ResponseEntity<> 사용
@GetMapping("/v2/response-body")
public ResponseEntity<String> responseBodyV2() {
return new ResponseEntity<>("data", HttpStatus.OK);
}
Postman
Response Body에 data라는 문자열과 HttpStatus.OK에 해당하는 상태 코드를 반환한다.
ResponseEntity는 HttpEntity 를 상속받았다.
HttpEntity는 HTTP Message의 Header, Body 모두 가지고 있다.
@ResponseBody(TEXT, JSON) 사용
@Data
@NoArgsConstructor // 기본 생성자
@AllArgsConstructor // 전체 필드를 인자로 가진 생성자
public class Tutor {
private String name;
private int age;
}
// TEXT 데이터 통신
@ResponseBody
@GetMapping("/v3/response-body-text")
public String responseBodyText() {
return "data"; // HTTP Message Body에 "data"
}
Postman
// JSON 데이터 통신
@ResponseBody
@GetMapping("/v3/response-body-json")
public Tutor responseBodyJson() {
Tutor tutor = new Tutor("wonuk", 100);
return tutor; // HTTP Message Body에 Tutor Object -> JSON
}
Postman
View를 사용하는 것이 아닌 HTTP Message Converter를 통해 HTTP Message Body를 직접 입력할 수 있다. → ResponseEntity와 같음
@ResponseStatus 를 사용하여 상태 코드를 지정할 수 있다.
@ResponseStatus(HttpStatus.OK)
@ResponseBody
@GetMapping("/v4/response-body")
public Tutor responseBodyV4() {
Tutor tutor = new Tutor("wonuk", 100);
return tutor;
}
Postman
단, 응답 코드를 조건에 따라서 동적으로 변경할 수는 없다.
ex) 1번의 경우 OK, 2번의 경우 Created
ResponseEntity<Object>(JSON)
@ResponseBody
@GetMapping("/v5/response-body")
public ResponseEntity<Tutor> responseBody() {
Tutor tutor = new Tutor("wonuk", 100);
return new ResponseEntity<>(tutor, HttpStatus.OK);
}
Postman
ResponseEntity<>두 번째 파라미터에 Enum을 사용하여 상태 코드를 바꿀 수 있다.
HTTP Message Converter를 통하여 JSON 형태로 변환되어 반환된다.
동적으로 응답 코드를 변경할 수 있다.
@ResponseBody
@GetMapping("/v5/response-body")
public ResponseEntity<Tutor> responseBody() {
Tutor tutor = new Tutor("wonuk", 100);
if (조건) {
return new ResponseEntity<>(tutor, HttpStatus.OK);
} else {
return new ResponseEntity<>(tutor, HttpStatus.BAD_REQUEST);
}
}
📌 데이터를 표현하기 위한 가볍고 간단한 텍스트 기반의 데이터 교환 형식입니다. 키-값 쌍으로 데이터를 구조화하며, 사람과 기계가 읽고 쓰기 쉽도록 설계되었습니다. 웹 애플리케이션과 서버 간의 데이터 교환에서 널리 사용됩니다.
Json은 @RestController 에서 가장 많이 사용되는 데이터 형식이다. 현재 대부분의 API는 Request, Response 모두 JSON 형태로 통신한다.
Json 형태로 Data를 전송할 때는 Request Header의 content-type이 꼭 application/json 이여야 한다.
JSON의 특징
가독성:
간단한 문법으로 사람이 읽기 쉽습니다.
경량성:
XML에 비해 데이터 표현이 간결하여 네트워크 트래픽이 적습니다.
언어 독립성:
대부분의 프로그래밍 언어에서 JSON을 쉽게 생성하고 파싱할 수 있습니다.
구조화된 데이터 표현:
객체, 배열, 숫자, 문자열 등 다양한 데이터 타입을 지원합니다.
JSON의 데이터 타입
문자열
"hello"
큰따옴표로 묶인 텍스트.
숫자
123, 45.67
정수 및 실수 지원.
불리언
true, false
논리 값.
객체
{ "key": "value" }
키-값 쌍의 집합.
배열
[1, 2, 3]
여러 값의 순서 있는 리스트.
null
null
값이 없음.
JSON 처리 (Java 예제)
a. Java 객체 → JSON 변환
Spring Boot에서 Jackson 라이브러리를 사용하여 JSON 데이터를 처리할 수 있습니다.
import com.fasterxml.jackson.databind.ObjectMapper;
public class JsonExample {
public static void main(String[] args) throws Exception {
ObjectMapper objectMapper = new ObjectMapper();
// 객체 생성
User user = new User("John", 30);
// 객체를 JSON으로 변환
String json = objectMapper.writeValueAsString(user);
System.out.println(json);
}
}
class User {
private String name;
private int age;
// Constructor, Getters, Setters
public User(String name, int age) {
this.name = name;
this.age = age;
}
// Getters and Setters
}
@Data
public class Tutor {
private String name;
private int age;
}
@Controller
public class ModelAttributeController {
@ResponseBody
@PostMapping("/v1/tutor")
public String requestParamV1(
@RequestParam String name,
@RequestParam int age
) {
Tutor tutor = new Tutor();
tutor.setName(name);
tutor.setAge(age);
return "tutor name = " + name + " age = " + age;
}
}
@RequestParam 의 Mapping을 사용하게 되면 위와 같은 객체를 생성하는 코드가 포함된다.
@ModelAttribute 는 해당 과정을 자동화 한다.
Postman
POST /v1/tutor
content-type: application/x-www-form-urlencoded
name=wonuk&age=100
@ResponseBody
@PostMapping("/v2/tutor")
public String modelAttributeV2(
@ModelAttribute Tutor tutor
) {
String name = tutor.getName();
int age = tutor.getAge();
return "tutor name = " + name + " age = " + age;
}
Postman
POST /v2/tutor
content-type: application/x-www-form-urlencoded
name=wonuk&age=100
@ModelAttirubte 동작 순서
파라미터에 @ModelAttribute가 있으면 파라미터인 Tutor 객체를 생성한다.
요청 파라미터 이름으로 객체 필드의 Setter를 호출해서 바인딩한다.
파라미터 이름이 name 이면 setName(value); 메서드를 호출한다.
파라미터 이름과 필드 이름이 반드시 같아야 한다!
@Data의 Setter가 없다면?
@Getter
public class Tutor {
private String name;
private int age;
}
POST /v3/tutor
content-type: application/x-www-form-urlencoded
name=wonuk&age=100
@ResponseBody
@PostMapping("/v3/tutor")
public String modelAttributeV3(Tutor tutor) {
String name = tutor.getName();
int age = tutor.getAge();
return "tutor name = " + name + " age = " + age;
}
Spring에서는 @RequestParam이나 @ModelAttribute가 생략되면
String, int, Integer 와 같은 기본 타입은 @RequestParam과 Mapping한다. V4
@ResponseBody
@PostMapping("/v4/tutor")
public String requestParamV2(
String name,
int age
) {
return "tutor name = " + name + " age = " + age;
}
나머지 경우들(객체)은 모두 @ModelAttribute 와 Mapping한다. V3
@RequestParam vs @ModelAttribute 차이
주요 차이점
@RequestParam
@ModelAttribute
목적
특정 **단일 파라미터(쿼리 파라미터, 폼 데이터)**를 매핑.
요청 데이터를 객체 형태로 매핑.
대상 데이터
단일 Key-Value 쌍 (예: ?key=value)
여러 Key-Value 쌍을 객체의 필드에 매핑.
적용 대상
개별 매개변수.
객체.
데이터 출처
쿼리 파라미터, 폼 데이터.
폼 데이터, 쿼리 파라미터, 경로 변수 등.
기본값 설정
defaultValue 속성을 통해 가능.
객체 필드에 기본값을 설정하거나, 빈 객체 생성.
뷰 데이터 전달
뷰 데이터 전달 기능 없음.
뷰에 데이터를 전달할 수 있음 (메서드 레벨 사용).
생략 가능 여부
생략 불가능 (명시적으로 사용해야 함).
매개변수에서 생략 가능 (Spring이 자동으로 객체를 매핑).
주요 사용 사례
단순 쿼리 파라미터 또는 단일 데이터 처리.
폼 데이터나 복잡한 데이터 구조(객체) 처리.
사용 목적에 따른 선택
@RequestParam
요청 데이터가 단순한 Key-Value 쌍이고, 각각 개별적으로 처리할 경우.
쿼리 파라미터나 단일 폼 데이터 값에 적합.
@ModelAttribute
요청 데이터가 객체로 표현 가능한 경우.
복잡한 폼 데이터(여러 필드가 있는 객체)를 처리하거나, 뷰와 데이터를 쉽게 연동할 때 유리.
요약
상황
선택
단일 쿼리 파라미터 처리.
@RequestParam
복잡한 폼 데이터를 객체로 매핑.
@ModelAttribute
기본값 설정이 필요한 경우.
@RequestParam
뷰에 데이터를 전달해야 하는 경우.
@ModelAttribute
객체 기반 데이터 처리가 필요한 경우.
@ModelAttribute
결론
**@RequestParam**은 단일 데이터(Key-Value) 처리에 적합하며, 간단한 요청에 사용됩니다.
**@ModelAttribute**는 폼 데이터나 요청 데이터를 객체 형태로 처리하거나, 뷰와 연동된 데이터를 전달할 때 유용합니다.
@RequestParam, @ModelAttribute는 GET + Query Parameter와, POST HTML Form Data를 바인딩하는 방법이다.
HTTP Message Body(요청)
📌HTTP 요청(Request) 또는 응답(Response)에서실제 데이터를 담는 부분입니다.
주로 클라이언트와 서버 간에 전송되는JSON, XML, HTML, 바이너리 파일, 텍스트 등 다양한 콘텐츠를 포함합니다.
특징
이제부터 배울 내용은 HTTP Message Body에 직접적으로 Data가 전달되는 경우이다.
Request Body의 Data를 바인딩하는 방법이다.
REST API에서 주로 사용하는 방식이다.
HTTP Method POST, PUT, PATCH에서 주로 사용한다.
GET은 Request Body가 존재할 수는 있지만 권장하지 않는다.
JSON, XML, TEXT 등을 데이터 형식으로 사용한다.
HTTP Message 구조
HTTP Request, Response 예시
Server에서 Request로 전달받은 Data를 처리하기 위해서 바인딩 해야 한다.
ex)JSON → Object
TEXT
📌 HTTP Request Body에 Data가 전송되는 경우 HttpMessageConverter를 통해 바인딩된다.
현대에는 Restful API를 주로 사용하고 있어서 대부분의 경우 JSON 형식으로 통신한다.
@PostMapping("/v3/request-body-text")
public HttpEntity<String> requestBodyTextV3(HttpEntity<String> httpEntity) {
// HttpMessageConverter가 동작해서 아래 코드가 동작하게됨
String body = httpEntity.getBody();
return new HttpEntity<>("response = " + body); // 매개변수 = Body Message
}
Postman
Spring의 HttpMessageConverter 덕분에 간편하게 Request Data에 접근할 수 있다.
HttpEntity를 사용하면 HttpMessageConverter가 동작하여 자동으로 매핑된다.
요청 뿐만이 아닌 응답까지 HttpEntity 하나만으로 사용이 가능해진다.
HttpEntity
📌HTTP 요청(Request)와 응답(Response)의 헤더(Header)와 본문(Body)을 캡슐화하는 데 사용됩니다.
HttpEntity는 HTTP Header, Body 정보를 편리하게 조회할 수 있도록 만들어준다.
주요 특징
헤더(Header)와 바디(Body) 모두를 포함:
HTTP 요청 또는 응답의 헤더와 바디를 관리.
Immutable 객체:
HTTP 메시지를 불변(Immutable) 상태로 다룸.
Spring의 HTTP 클라이언트와 서버 모두에서 사용 가능:
REST API 호출에서 요청을 보낼 때, 응답 데이터를 받을 때 활용.
HttpEntity 역할
Http Request Body Message를 직접 조회한다
Request 뿐만 아니라 Response도 사용할 수 있도록 만들어준다.
Response Header 또한 사용할 수 있다.
Request Parameter를 조회하는 기능들과는 아무 관계가 없다.
View를 반환하지 않는다.
주요 클래스
HttpEntity는 Spring에서 두 가지 주요 클래스의 기반이 됩니다:
RequestEntity:
HTTP 요청을 표현.
요청의 헤더, URL, HTTP 메서드 등을 캡슐화.
HTTP Request Method, URL 정보가 추가 되어있다.
ResponseEntity:
HTTP 응답을 표현.
응답의 상태 코드, 헤더, 바디를 관리.
HTTP Response 상태 코드 설정이 가능하다.
@Controller
public class RequestBodyStringController {
@PostMapping("/v4/request-body-text")
public HttpEntity<String> requestBodyTextV4(RequestEntity<String> httpEntity) {
// HttpMessageConverter가 동작해서 아래 코드가 동작하게됨
String body = httpEntity.getBody();
// url, method 사용 가능
return new ResponseEntity<>("response = " + body, HttpStatus.CREATED); // Body Data, 상태코드
}
}
Postman
위 방법을 적용해도 불편하다.
Data를 httpEntity에서 꺼내어 사용해야 한다.
Spring은 Http RequestBody Message를 읽어서 String이나 Object로 자동으로 변환해준다. 이때HttpMessageConverter가 사용된다.
@RequestBody, @ResponseBody
📌Spring에서 @RequestBody, @ResponseBody 어노테이션을 사용하면 각각 Request, Response 객체의 Body에 편하게 접근하여 사용할 수 있다.
@RequestMapping("/prefix")
@RestController
public class RequestMappingController {
// Post, GET, Put, Patch, Delete 모두 가능
@GetMapping(value = "/v3")
public String exampleV3() {
// logic
return "this is sparta!";
}
}
@PathVariable
📌 URL 경로에 포함된 변수를 메서드의 매개변수로 전달하기 위해 사용됩니다. 주로RESTful 웹 서비스에서 동적인 요청 처리를 위해 사용됩니다.
HTTP 특성 중 하나인 비연결성을 극복하여 데이터를 전달하기 위한 방법 중 하나이다. URL로 전달된 값을 파라미터로 받아오는 역할을 수행한다.
동작 원리
URL 경로에 **변수(placeholder)**를 정의하고, 해당 값을 컨트롤러 메서드의 매개변수로 전달합니다.
@PathVariable은 요청 경로에서 변수 값을 추출하여 메서드 파라미터에 바인딩합니다.
@PathVariable
경로 변수를 중괄호에 둘러싸인 값으로 사용할 수 있다.
ex) user/{id}
기본적으로 @PathVariable로 설정된 경로 변수는 반드시 값을 가져야 하며 값이 없으면 응답 상태코드 404 Not Found Error가 발생한다.
최근 Restful API를 설계하는 것이 API의 기준이 되며 해당 어노테이션의 사용 빈도가 높아졌다.
@RequestMapping("/posts")
@RestController
public class PathVariableController {
// postId로 된 post 단건 조회
@GetMapping("/{postId}")
public String pathVariableV1(@PathVariable("postId") Long data) {
// logic
String result = "PathvariableV1 결과입니다 : " + data;
return result;
}
}
@RequestMapping("/posts")
@RestController
public class PathVariableController {
// 변수명과 같다면 속성값 생략가능
@GetMapping("/{postId}")
public String pathVariableV2(@PathVariable Long postId) {
// logic
String result = "PathvariableV2 결과입니다 : " + postId;
return result;
}
}
2. @PathVariable 다중 사용 가능
@RestController
public class PathVariableController {
@GetMapping("/{postId}/comments/{commentId}")
public String pathVariableV3(
@PathVariable Long postId,
@PathVariable Long commentId
) {
// logic
String result = "PathvariableV3 결과입니다 postId : " + postId + "commentsId : " + commentId;
return result;
}
}
@RequestMapping("/posts/{postId}")
@RestController
public class PathVariableController {
@GetMapping("/comments/{commentId}")
public String pathVariableV4(
@PathVariable Long postId,
@PathVariable Long commentId
) {
// logic
String result = "PathvariableV4 결과입니다 postId : " + postId + "commentsId : " + commentId;
return result;
}
}
특정 파라미터 매핑
📌 속성 설정을 통하여 특정 헤더, 특정 파라미터와 Mapping 할 수 있다.
Parameter 추가 매핑
특정 파라미터와 매핑하는 방법
package com.example.springbasicannotation.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class ParameterController {
// parms 속성값 추가
@GetMapping(value = "/users", params = "gender=man")
public String params() {
// logic
String result = "params API가 호출 되었습니다.";
return result;
}
}
실제 URL GET http://localhost:8080/users**?gender=man** 파라미터가 있어야 호출된다.
실행결과
파라미터가 없다면?
400 Bad Request 클라이언트 측 에러
속성 작성 규칙
params = "gender"
params의 key값은 커스텀이 가능하다
value는 없어도 된다.
params = "!gender"
gender가 없어야 한다.
params = "gender=man"
gender=man 이어야 한다.
params = "gender!=man"
params의 value값이 man가 아니여야 한다.
params = {"gender=man", "gender=woman"}
배열로 속성 값을 여러 개 설정이 가능하다.
특정 Header 매핑
특정 Header와 매핑하는 방법
@RestController
public class ParameterController {
// headers 속성값 추가
@PostMapping(value = "/users", headers = "Content-Type=application/json")
public String headers() {
// logic
String result = "headers API가 호출 되었습니다.";
return result;
}
}
Postman → Body → raw → JSON
Postman → Headers → hidden
HTTP Header를 사용하기 때문에 Postman으로 테스트 해야 한다.
ex) key=Content-Type / value=application/json
실행결과
속성 작성 규칙은 위 params 속성 값의 규칙과 같다.
MediaType 매핑, consume(수용)
HTTP Header Content-Type(요청)과 매핑 된다.
@RestController
public class ParameterController {
// consumes 속성값 추가
@PostMapping(value = "/users", consumes = "application/json") // MediaType.APPLICATION_JSON_VALUE
public String consumes() {
// logic
String result = "consumes API가 호출 되었습니다.";
return result;
}
}
consumes 속성 value값으로는 이미 Spring에서 제공되는 Enum인
MediaType.APPLICATION_JSON_VALUE 형태로 사용한다.
Postman → Body → raw → JSON
Postman → Body → raw → JSON
파라미터가 없거나 다르다면?
HTTP 상태코드 405 Unsupported Media Type Exception 발생
속성 작성 방법
consumes=”application/json”
application/json 미디어 타입 허용
consumes=”!application/json”
application/json 제외 미디어 타입 허용
consumes=”application/*”
application/ 으로 시작하는 모든 미디어 타입 허용
consumes=”*\\/*”
모두 허용
MediaType 매핑 produces(제공)
요청 헤더의 Accept 값에 따라서 produces 하는 값이 변한다.
@RestController
public class ParameterController {
// produces 속성값 추가
@GetMapping(value = "/users", produces = "text/plain")
public String produces() {
// logic
String result = "text/plain 데이터 응답";
return result;
}
}
Map과 유사하게 Key, Value 형식으로 구현되어 있지만 하나의 Key가 여러 Value를 가질 수 있다 HTTP Header, Reqeust Parameter와 같이 하나의 Key에 여러 값을 받을 때 사용한다.
ex ) key1=value1&key1=value2
MultiValueMap<String, String> linkedMultiValuemap = new LinkedMultiValueMap();
// key1에 value1 저장
linkedMultiValuemap.add("key1", "value1");
// key1에 value2 저장
linkedMultiValuemap.add("key1", "value2");
// key1에 저장된 모든 value get
List<String> values = linkedMultiValuemap.get("key1");
간단한 어노테이션으로getter, setter, equals, hashCode, toString, logger 생성 등을 자동으로 생성하여 코드의 간결성을 높이고 가독성을 향상시킵니다.
import lombok.ToString;
@ToString
public class Example {
private String name;
private int age;
}
=
@Override
public String toString() {
return "Example(name=" + name + ", age=" + age + ")";
}
Lombok의 장점
코드 간소화:
getter, setter, equals, toString 등 반복적인 코드를 줄여줍니다.
가독성 향상:
핵심 로직에만 집중할 수 있어 코드가 더 읽기 쉬워집니다.
유지보수성 개선:
코드 중복이 줄어들어 수정할 곳이 줄어듭니다.
Lombok 사용 시 주의사항
의존성 문제:
Lombok은 컴파일 시점에 코드를 생성하므로, IDE와 빌드 환경이 Lombok을 지원해야 합니다.
타인의 코드 리뷰:
Lombok을 사용하면 실제 코드가 IDE에서 보이지 않아, 팀원이 Lombok을 모른다면 코드 리뷰가 어려울 수 있습니다.
Java 표준 아님:
Lombok은 Java 표준 라이브러리가 아니기 때문에, 프로젝트 환경에 따라 사용을 제한할 수 있습니다.
@Slf4j
📌 Lombok에서 제공하는 어노테이션으로, SLF4J(Simple Logging Facade for Java) 기반의 로깅(Logger) 객체를 자동으로 생성합니다.
로깅은 애플리케이션 개발에서 로그 메시지를 기록하여 디버깅, 모니터링, 운영 상태를 파악하는 데 매우 중요한 도구입니다.
Slf4j는 인터페이스이고 그 구현체로 Logback같은 라이브러리를 선택한다. 실제 개발에서는 Spring Boot가 기본으로 제공하는 Logback을 대부분 사용한다. (Slf4j는 껍데기 실제 로깅은 구현체가 한다.)
헷갈릴까봐 기술하면, Logback이 Slf4j의 구현체 중 하나로, Spring Boot에서 기본 로깅 프레임워크로 사용된다.
Logging
Thread 정보, 클래스 이름과 같은 부가 정보를 함께 확인할 수 있다.
실제 운영 환경에서는 System.out.println();을 사용하여 Console에 정보를 출력하지 않고, 별도의 로깅 라이브러리를 사용하여 로그를 출력한다.
Log Level 설정을 통하여 Error 메세지만 출력하도록 하도록 하기도 하고 로그 메세지를 일자별로 모아서 저장하여 외부 저장소에 보관하기도 한다.
Log Level
TRACE > DEBUG > INFO > WARN > ERROR
이게 왜 있나 싶을 수 있는데, 서버는 출력을 터미널에 띄울 수 없다보니 따로 서버내에서 기록하게 한다.실제로 개발자 환경에 console에서 그 결과를 확인할 수 있다. 더 나아가 오류를 미리 기록하여 모니터링을 돕는다.서버에 적재하지 않는 프로그램이면 이렇게 하지 않겠지만 서버는 24시간 돌아가니 사람이 24시간 감시할거 아니면 저런 장치가 필요하다.
사용시 주의점
package com.example.springbasicannotation.controller;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.*;
@Slf4j
@RestController
public class Slf4jController {
@RequestMapping("/logging")
public String logging() {
String sparta = "Sparta";
// TRACE -> DEBUG -> INFO -> WARN -> ERROR
log.trace("문자 trace={}", sparta);
log.debug("문자 debug={}", sparta);
// default
log.info("문자 info={}", sparta);// 문자 연산을 진행하지 않는다.
log.warn("문자 warn={}", sparta);
log.error("문자 error={}", sparta);
log.info("문자 info " + sparta); // 문자 연산을 먼저 해버린다.
return "success";
}
}
# com.example.springbasicannotation 하위 경로들의 로그 레벨을 설정한다.
logging.level.com.example.springbasicannotation=TRACE
Postman 호출
Default Level(INFO) API 호출
출력결과
level=TRACE
@Controller VS @RestController
📌 Annotation 기반의 Spring에서 Controller(Handler)를 만들 때 사용하는 어노테이션
둘이 기능은 같지만, 데이터 반환 방식과 응답 처리 방식이 다르다.
주요 차이점
특징
@Controller
@RestController
주요 용도
페이지(View) 기반 웹 애플리케이션
RESTful API 개발
기본 반환 타입
View 이름(HTML, JSP 등)
JSON, XML 등 데이터
View Resolver
View Resolver를 통해 뷰 파일로 매핑
사용하지 않음
응답 내용
HTML 페이지를 렌더링하여 반환
데이터 자체를 HTTP 응답으로 반환
애너테이션 결합
단일 어노테이션
@Controller + @ResponseBody
언제 사용해야 할까?
@Controller:
HTML, JSP 같은 페이지 기반 웹 애플리케이션 개발.
템플릿 엔진(Thymeleaf, JSP)과 함께 사용.
@RestController:
JSON, XML 데이터를 반환하는 RESTful API 개발.
클라이언트(브라우저, 앱 등)가 데이터를 요청하고 처리하는 백엔드 서비스 개발.
@Controller
📌MVC(Model-View-Controller) 아키텍처에서 사용되는 컨트롤러.
클라이언트 요청을 처리하고, **View(HTML, JSP 등)**를 반환하는 데 사용.
View가 있는 경우에 사용한다.
주로 페이지 기반의 웹 애플리케이션 개발에 적합.
즉, Template Engine인 Thymeleaf, JSP 등을 사용하는 경우
특징
View Resolver와 함께 사용:
@Controller는 뷰 이름을 반환하며, Spring의 View Resolver가 이 이름을 실제 뷰 파일 경로로 변환.
예: return "home"; → /WEB-INF/views/home.jsp
주요 반환 타입:
문자열(String): 뷰 이름.
ModelAndView: 데이터와 뷰 정보를 함께 반환.
@Controller
public class WebController {
@GetMapping("/hello")
public String hello(Model model) {
model.addAttribute("message", "Hello, World!");
return "hello"; // 뷰 이름 반환 (예: hello.jsp)
}
}
응답 흐름
클라이언트가 /hello로 요청.
hello() 메서드가 실행되고, 뷰 이름 "hello" 반환.
View Resolver가 "hello"를 실제 뷰 파일 경로(/WEB-INF/views/hello.jsp)로 매핑.
해당 JSP 파일이 렌더링되어 클라이언트에게 HTML 응답 반환.
@Target(ElementType.Type)
Class, Interface, Annotation, Enum, Record Declaration(Java16) 에 적용할 수 있다.
📚 Servlet을 지원하는 WAS 내부에는 서블릿 컨테이너가 있다. 서블릿 컨테이너는 서블릿을 초기화, 생성, 관리, 호출, 종료하는 역할을 수행한다.
Servlet의 생명주기
Servlet은 서블릿 컨테이너가 생성 및 관리한다.
즉, WAS(서블릿 컨테이너 포함)가 종료될 때 Servlet도 함께 종료된다.
Servlet 객체 생성시점
개발자가 직접 인스턴스화 하여 사용하는것이 아닌, 코드만 작성하면 서블릿 컨테이너가 생성한다.
서블릿 예시 코드
@WebServlet(name="ExampleServlet", urlPatterns = "/example")
public class ExampleServlet extends HttpServlet { // HttpServlet을 상속받아 구현한다.
@Override
protected void service(
HttpServletRequest request, // HTTP 요청 정보를 쉽게 사용할 수 있게 만드는 Servlet
HttpServletResponse response // HTTP 응답 정보를 쉽게 제공할 수 있게 만드는 Servlet
) {
// application logic
}
}
@WebServlet(name="Example2Servlet", urlPatterns = "/example2")
// 위와 같은 코드
@WebServlet(name="Example3Servlet", urlPatterns = "/example3")
// 위와 같은 코드
@WebServlet(name="Example4Servlet", urlPatterns = "/example4")
// 위와 같은 코드
Servlet Container가 하는 일
서블릿을 초기화, 생성, 관리, 호출, 종료하는 역할을 수행
Servlet 객체를 싱글톤으로 관리한다.
동시 요청에 대한 처리를 위해 Multi Thread를 지원한다.
💬 Q. 싱글톤이 무엇인가요?
A. 싱글톤은 객체를 하나만 생성하여 생성된 인스턴스를 공유하여 사용하는것을 의미합니다. 특정 클래스의 인스턴스가 여러개 생성되지 않도록 하여 자원의 낭비를 방지하고, 인스턴스를 공유함으로써 상태를 일관되게 유지하기 위함입니다. 하지만, 공유 변수 사용을 주의해야 합니다.
@Indexed
클래스가 컴포넌트 스캔의 대상으로 Spring Bean에 더 빠르게 등록되도록 도와준다.
Spring Bean, 컴포넌트 스캔에 대해서는 숙련주차 강의에서 자세히 다룰 예정
@Target
@Target 이 선언된 하위 어노테이션이 어떤 범위에 적용되는지 설정한다.
ElementType Enum 속성
각각의 Enum마다 적용되는 범위가 상단에 주석으로 설명되어 있다.
@Retention
@Retention 하위의 어노테이션이 얼마나 오래 유지되는지를 결정한다.
RetentionPolicy Enum 속성
SOURCE
소스 코드(.java)에서만 유지된다.
컴파일러에 의해 클래스 파일로 저장되지 않는다.
CLASS
컴파일된 클래스 파일(.class)에 저장되지만, JVM이 실행 시 읽지 않는다. (주석과 같음)
서버는 고객이 요청한 **주문 정보(예: 치킨 배달)**를 확인하고, 이 요청을 처리할 적절한 음식점(Handler)을 찾아야 합니다.
여기서Handler Mapping은주문에 맞는 음식점을 조회하는 과정입니다.
예: 고객이 "치킨"을 주문했으니, 근처의 치킨집을 선택합니다.
3. Handler를 처리할 Adapter 조회
음식점마다 주문을 처리하는 방식(프로세스)이 다를 수 있습니다.
어떤 음식점은 앱을 통해 바로 확인하고,
어떤 음식점은 전화로 주문을 확인해야 합니다.
이 단계에서는 요청을 처리할 수 있는 적절한 **Handler Adapter(음식점과 서버를 연결하는 도구)**를 찾습니다.
예: 치킨집은 앱으로 주문을 확인하는 시스템이 있으니,앱 기반 주문 어댑터를 선택.
4. Handler Adapter 실행(handle)
적절한 **Handler Adapter(주문 어댑터)**가 음식점에 주문을 전달합니다.
예: 앱이 "치킨 한 마리 주문 요청"을 음식점의 주문 시스템에 보냅니다.
5. Handler 실행(호출)
음식점(Handler)이 실제로 주문을 준비하기 시작합니다.
예: 주방에서 치킨을 튀기고 포장합니다.
6. Model And View 반환(return)
음식점은 준비가 끝난 뒤, "주문이 완료되었습니다!"라는 메시지와 함께 준비된 치킨 데이터를 서버에 보냅니다.
예: "치킨 1마리, 포장 완료!"
여기서ModelAndView는 이 데이터("치킨 데이터")와 응답 메시지를 함께 묶어서 반환하는 역할을 합니다.
7. View Resolver 호출 (알맞은 View 요청)
서버는 고객에게 응답을 보내기 전에, 결과 데이터를 어떻게 보여줄지 결정합니다.
예: 고객이 앱을 통해 결과를 볼 수 있어야 하므로, 앱 화면(View)을 설정해야 합니다.
View Resolver는 "치킨 준비 완료"라는 정보를 앱의 알맞은 화면(예: 주문 완료 페이지)으로 연결합니다.
8. View 반환
View Resolver는 "주문 완료 화면"을 앱에 전달합니다.
예: 고객의 앱에 "주문 완료! 배달 중!"이라는 화면이 나타남.
9. View Rendering
고객의 앱에서 실제로 화면이 표시됩니다.
예: 고객은 "주문이 완료되었고, 곧 배달됩니다!"라는 메시지를 화면에서 확인합니다.
결론: 배달 서비스로 비유한 실행 흐름
고객이 배달 앱에 주문 요청을 보냄 (HTTP 요청)
서버가 요청을 처리할 음식점을 찾음 (Handler Mapping)
주문을 전달하는 적절한 방식을 선택 (Handler Adapter 조회)
음식점이 주문을 준비함 (Handler 실행)
음식점이 준비 상태를 서버에 반환 (ModelAndView 반환)
서버가 결과를 앱 화면에 맞게 변환 (View Resolver 호출)
결과가 앱 화면에 표시됨 (View Rendering)
요약
DispatcherServlet ( 요청과 응답의 중앙 처리국 )
클라이언트 HTTP Request를 알맞게 파싱하고 클라이언트에게 알맞은 응답을 반환
핸들러 목록 정보를 알고있다.
핸들러 어댑터 목록 정보를 알고있다.
HandlerAdapter (부서 담당 연결원)
자신이 처리할 수 있는 Handler인지 확인할 수 있는 기능(Method)이 필요하다.
프론트 컨트롤러에서 요청을 위임받았을 때 핸들러에게 요청을 지시하는 기능이 필요하다.
return 시 Handler로부터 전달받은 결과를 알맞은 응답으로 변환한다.
Handler (처리자)
요청에 대한 로직을 수행하는 기능이 필요하다.
Dispatcher Servlet
📌 모든 HTTP 요청의 진입점으로 작동하는 프론트 컨트롤러(Front Controller)로, 요청 처리의 중앙 허브(총괄), 핸들러 매핑(배정), 핸들러 어댑터 실행(인력 파견), 응답 반환(우편전달)을 다 한다.
Spring MVC의 프론트 컨트롤러는Dispatcher Servlet(Servlet의 한 종류)이다.
Dispatcher Servlet은 HttpServlet을 상속 받아서 사용하고 Servlet의 한 종류이다.
Spring Boot는 Dispatcher Servlet을 서블릿으로 자동으로 등록(내장 Tomcat WAS를 실행하면서 등록한다)하고 모든 URL 경로에 대해서 Dispatcher Servlet을 Mapping 한다. → (urlPatterns=”/”) = 요청이 들어오는 모든 url에 총괄 관리자를 붙인다.
더 자세한 URL 경로가 높은 우선순위를 가진다. = 요구사항이 자세한 손님부터 처리해 주겠다는 것 = 효율적이라서
개발자가 만들 Servlet이 항상 우선순위가 높아서 실행된다.
DispatcherServlet의 service()
Servlet이 호출되면 HttpServlet이 제공하는 service()가 호출된다.
Spring MVC는 DispatcherServlet의 부모인 FrameworkServlet에서 service()를 Override 해두었다.
FrameworkServlet.service()를 시작으로 여러 메서드가 호출됨과 동시에 가장 중요한DispatcherServlet.doDispatch()가 호출된다.
📌 Spring MVC는 DispatcherServlet 코드의 변경 없이 기능변경 및 확장이 가능하다. 기능들이 대부분 Interface로 만들어져 있기 때문이다.
이쯤에서 한번 더 짚고 넘어가면 왜 대부분이 클래스가 아니라 인터페이스로 구현되어 있냐는 질문엔, 다형을 위해서가 정답이다.
org.springframework.web.servlet
HandlerMapping
HandlerAdapter
ViewResolver
View
당연히 이 모든 인터페이스를 알 필요는 없다. 하지만 자주 사용하는 인터페이스에 대해서는 잘 알아야 확장이나 구현, 문제 해결에 있어 용이하다.
Controller Interface
📌Spring 2.5 이전에 모든 컨트롤러가 구현해야 했던 표준 인터페이스입니다. 이 인터페이스는 클라이언트의 요청을 처리하고, 결과를 View로 전달하는 기본적인 방법을 정의합니다.
Controller Interface를 implements 하여 구현하게되면 개발자가 원하는 Controller(Handler)를 사용할 수 있게됩니다.
추후 강의에 등장할 현대에 사용하는 Annotation 기반 Spring의 @Controller와는 역할이 비슷하지만 연관은 없습니다.
package com.example.springbasicmvc.controller;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.Controller;
// Spring Bean 이름을 URL로 설정
@Component("/example-controller")
public class ExampleController implements Controller {
@Override
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
System.out.println("example-controller가 호출 되었습니다.");
return null;
}
}
http://localhost:8080/example-controller 로 HTTP 요청을 하게 되면 응답결과가 반환된다.
출력 결과
@Component
Spring Bean에 등록하는 역할을 수행한다.
Spring Bean은 애플리케이션의 구성 요소를 정의하는 객체이다.
마치 Servlet이 Servlet Container에 등록되는 것과 같다.
Handler Mapping
핸들러 매핑에서 ExampleController( Spring 애플리케이션에서 특정 요청을 처리하는 컨트롤러 클래스)를 찾을 수 있어야 한다.
→ Spring Bean의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑이 필요하다.
Handler Adapter
Handler Mapping을 통해 찾은 핸들러를 실행할 수 있는 Handler Adapter가 필요
→ Controller Interface를 실행할 수 있는 Handler Adapter를 찾고 실행한다.
놀랍게도 Handler Mapping은 찾기만 하고 Handler Adapter가 Handler에게 배치해줘야 한다.
유지보수와 확장성에 용이하다...
Spring Boot의 Handler Mapping, Handler Adapter
📌 Spring Boot를 사용하면 개발에 필요하여 자동으로 등록되는 HandlerMapping과 HandlerAdapter들이 있다.
HandlerMapping, HandlerAdapter 모두 우선순위대로 조회한다.
HandlerMapping
우선순위 순서
RequestMappingHandlerMapping
우선순위가 가장 높다
Annotation 기반 Controller의 @RequestMapping에 사용
BeanNameUrlHandlerMapping(위 예시코드에 사용)
Spring Bean Name으로 HandlerMapping
HandlerAdapter
우선순위 순서
RequestMappingHandlerAdapter
Annotation 기반 Controller의 @RequestMapping에서 사용
HttpRequestHandlerAdapter
HttpRequestHandler 처리
SimpleControllerHandlerAdapter(위 예시코드에 사용)
Controller Interface 처리
@RequestMapping 은 가장 높은 우선순위의 HandlerMapping인 RequestMappingHandlerMapping 과 가장 높은 우선순위의 HandlerAdapter인 RequestMappingHandlerAdapter 두가지를 사용하며 현대에 사용하는 Annotation 기반의 컨트롤러를 지원한다.
HttpRequestHandler로 알아보는 Spring MVC 동작 순서
// 인터페이스
public interface HttpRequestHandler {
void handleRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException;
}
// 구현체
@Component("/request-handler")
public class ExampleRequestHandler implements HttpRequestHandler {
@Override
public void handleRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
System.out.println("request-handler Controller 호출");
// 구현 로직
}
}
@Component("/error-controller")
public class WhitelabelErrorController implements Controller {
@Override
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
System.out.println("error-controller가 호출 되었습니다.");
// viewName "sparta"는 존재하지 않는다.
return new ModelAndView("sparta");
}
}
컨트롤러는 호출되지만 View를 못 찾아 Whitelabel Error Page를 응답한다.
Spring Boot의 ViewResolver
📌 Spring Boot를 사용하면 개발에 필요하여 자동으로 등록되는 ViewResolver들이 있다.
우선순위 순서
아래 두 가지 이외에도 많은 ViewResolver가 존재한다.
BeanNameViewResolver
Bean Name으로 View를 찾아 반환
InternalResourceViewResolver(위 예시코드)
application.properties 설정 파일에 등록한 prefix, suffix 설정 정보를 사용하여 ViewResolver 등록
// 아래 코드를 자동으로 해주는것과 마찬가지이다.
@Bean
InternalResourceViewResolver internalResourceViewResolver() {
return new InternalResourceViewResolver("/WEB-INF/views", ".jsp");
}
InternalResourceViewResolver로 알아보는 Spring MVC 동작 순서
