MVC, 3 Layer
Spring MVC???
전통적인 동기식 웹 애플리케이션 개발을 위한 프레임워크
동기? 비동기?
동기 :
직렬적으로 태스크를 수행하는 방식
요청을 하면 하나의 태스크에서 응답이 나올 때까지 나머지 태스크는 대기를 한다
비동기:
병렬적으로 태스크를 수행하는 방식
요청을 하면 하나의 태스크에서 응답이 나오든 말든 상관없이 다음 태스크를 동작시킨다.
A함수에서 B함수로 요청을 할 때 콜백 함수를 함께 전달하고 B함수가 끝나면 콜백 함수를 실행시킨다.
동기식 요청- 응답 기반으로 동작
(클라이언트에서 요청을 하면 서버에서 요청을 처리하고 클라이언트로 응답을 한다,)
=================================================================
- 서블릿 api와 밀접하게 연동된다.
- 전통적인 웹 개발에 많이 사용되고 템플릿 엔진과 함께 뷰를 렌더링 한다.
- Http 프로토콜 기반으로 동작
- Restful웹 서비스 구축에도 자주 사용
=================================================================
Spring Batch??
대규모의 데이터 처리 작업을 배치로 실행하기 위한 프레임워크
Batch??
데이터 처리를 실시간으로 하는 것이 아니라 일괄 모아서 한 번에 처리하는 작업
응답이 빠르지 않아도 되는 작업을 하는데 적용할 수 있다.
특정 시간이후에는 자원을 사용하지 않는다.
==============================================
대량의 데이터를 처리한다.
특정 시간에 처리한다.
일괄적으로 처리한다.
대량의 데이터 처리에 적합한 배치 처리 모델을 제공
수동으로 실행되는 작업에 초점을 맞춤
Spring WebFlux
비동기식, 논블로킹 웹 애플리케이션 개발을 위한 프레임워크
블로킹?? 논블로킹??
A함수가 B함수를 호출을 했을 때 제어권을 어떻게 처리하느냐에 따라 다르다
블로킹:
A함수가 B함수를 호출을 했을 때 A함수가 가지고 있던 제어권을 B함수로 넘겨줘서 B함수가 끝날 때까지
A함수는 동작을 대기하고 있는다.
논블로킹:
A함수가 B함수를 호출했을 때 제어권을 넘겨주지 않고 계속 실행한다.
A함수, B함수 둘 다 실행 함
비동기 논블로킹 방식으로 요청을 처리
리액티브 스트림 기반 동작
비동기 논블로킹
A함수가 B함수를 호출할 때 콜백 함수를 함께 전달
B함수 실행 완료하면 콜백 함수 실행(비동기)
A함수가 제어권을 넘겨주지 않으니 A함수 계속 실행(논블로킹)
===========================================================
서버 자원의 효율성을 높이고 고성능 웹 애플리케이션을 구현하는 데 적합
데이터 스트림과 비동기 작업을 관리
많은 동시 연결을 효율적으로 처리 가능
서블릿 api를 사용하지 않고 논블로킹 서버를 사용 가능
=============================================================
웹 개발에 특화된 서비스
Spring MVC, Spring WebFlux
MVC??(디자인 패턴)
클라이언트와 서버 간의 구조
Model:
데이터와 비즈니스 로직을 다룸
데이터를 관리한다.(저장, 가져오기)
View:
사용자가 보는 페이지를 담당
화면에 페이지를 출력, 페이지에 데이터가 필요하면 데이터를 넣어서 화면에 출력
Controller:
모델과 뷰의 다리 역할
요청을 Controller에서 받아서 (데이터) Model 전달 -> 요청 처리(저장, 가져오기,...) ->
Controller에서 View로 전달 페이지 출력 데이터 필요할 때 데이터 받아서 페이지에 넣고 출력
전체적인 흐름 (요청 -> 컨트롤러 -> 모델 -> 컨트롤러 -> 뷰 -> 응답)
((페이지 출력 == 렌더링 버전), (Postman 요청, json형식 응답 == Restful Api 버전))
3 Layer
서버 개발 컨트롤러의 역할을 계층으로 분리
Controller:
프레젠테이션 레이어(Presentaion Layer)
사용자의 요청이 유효한지 검사, 필터링
요청 -> 데이터 전달
@Controller
== html를 리턴할 때 사용
@RestController
==json 형식 등 데이터를 리턴할 때 사용
위의 어노테이션을 사용하여 Controller로 사용한다고 지정해줘야 함
Service:
서비스 레이어(Service Layer)
비즈니스 로직을 처리하는 핵심 레이어
Controller와 Repository의 중간 다리 역할
요청 -> Controller(검증) -> Service(요청 처리(데이터 가공, 로직 실행)) -> Repository
@Service
Service로 사용한다는 어노테이션
Repository:
데이터 접근 레이어(Data Access Layer)
데이터베이스랑 상호작용 하는 레이어
저장, 수정, 제거 등 데이터베이스의 데이터를 처리
ORM 프레임 워크를 사용해 데이터베이스와 상호작용
ORM
객체와 데이터베이스 간의 데이터를 연결해 주는 도구
ORM은 객체지향 언어에서 객체와 데이터베이스 테이블 간의 매핑을 설정
객체의 상태를 데이터베이스에 저장하거나 데이터베이스에서 객체로 데이터를 가져오는 작업을 자동화
ORM 툴은 클래스와 테이블, 필드와 칼럼 간의 관계를 정의하는 매핑 파일이나 어노테이션을 사용
@Repository
Repository로 사용한다는 어노테이션
@Entity
Entiy로 사용한다는 어노테이션
데이터베이스 테이블과 매핑되는 도메인 객체
데이터베이스의 데이터를 가져오거나 저장할 때 사용
3 Layer 사용이유
1. 책임의 분리
세 계층으로 분리함으로써 각자의 역할만을 수행할 수 있도록 함
코드의 역할이 명확, 자신의 책임에 집중
2. 유지 보수성
역할이 분리되어 있어 기능을 수정하거나 추가할 때 관련 계층만 수정을 하면 됨.
코드의 복잡성 줄어듦, 유지보수 쉬워짐
3. 재사용성
특정 계층의 코드가 다른 애플리케이션에서 동일한 코드가 필요하면 그 계층만 재사용할 수 있다.
4. 테스트 용이성
계층이 독립적으로 구성되어 있기 때문에 계층을 쉽게 테스트할 수 있다.
Controller, Service를 단위 테스트를 하거나 Repository를 통합 테스트로 할 수 있다.
단위 테스트
소프트웨어의 가장 작은 단위를 독립적으로 테스트하여,
코드의 기본 기능이 정확한지 확인합니다. 빠르고, 자주 실행되며, 코드 내부의 로직을 검증하는 데 초점을 맞춥니다.
통합 테스트
여러 모듈을 결합하여 시스템이 제대로 작동하는지를 확인하는 테스트로,
모듈 간의 상호작용을 중점적으로 테스트합니다. 실제 환경에 가까운 상황에서 테스트를 수행하며,
단위 테스트보다 실행 시간이 길 수 있습니다.
5. 확장성
애플리케이션이 확장될 때, 계층이 독립적으로 확장이 가능하도록 도와줌
트래픽이 증가할 때 데이터를 관리하는 레이어를 독립적으로 확장 > 부하를 분산
트래픽
네트워크 내부에 일정 시간 동안 흐르는 데이터 양
6. 보안성
Controller에서 Service로 전달하기 전에 유효성 검사 가능
Service에서 비즈니스 로직을 통해 다시 유효성 검사 하여 안전한 데이터만 Repository로 전달
DTO
계층 간의 데이터를 이동시킬 때 사용
클라이언트에서의 요청에서 데이터를 요청받고 응답해줄 때 사용