[MVC]
1. 스프링 MVC는 Model-View-Controller(MVC) 아키텍처
(웹 애플리케이션의 각각의 역할을 분리하여 개발하고 유지보수할 수 있습니다.)
- 스프링 MVC의 주요 컴포넌트
DispatcherServlet
ㅡ 스프링 MVC의 핵심 컴포넌트로, 클라이언트의 요청을 받아들이고 적절한 핸들러에게 요청을 전달합니다. 또한, 컨트롤러에서 반환된 결과를 HTTP 응답으로 변환하여 클라이언트에게 반환합니다.
HandlerMapping
ㅡ DispatcherServlet이 클라이언트의 요청을 받았을 때, 요청을 처리할 핸들러(Controller)를 찾아주는 역할을 합니다.
Controller
ㅡ 클라이언트의 요청을 처리하고, 요청에 대한 비즈니스 로직을 실행하여 결과를 반환합니다.
ViewResolver
ㅡ Controller에서 반환한 결과를 보여줄 View를 찾아주는 역할을 합니다.
View
ㅡ Controller에서 반환한 결과를 실제로 화면에 출력하는 역할을 합니다.
-
스프링 MVC의 실행 흐름
1) 클라이언트의 요청이 DispatcherServlet으로 들어옵니다.
2) DispatcherServlet은 HandlerMapping을 이용하여 어떤 Controller가 요청을 처리할지 결정합니다.
3) 선택된 Controller는 클라이언트의 요청에 대한 비즈니스 로직을 실행하고, 결과를 반환합니다.
4) Controller가 반환한 결과는 ViewResolver를 통해 적절한 View로 변환됩니다.
5) 변환된 View는 클라이언트에게 응답으로 반환됩니다. -
스프링 MVC의 구성 요소
Model
ㅡ Controller에서 생성된 결과를 담는 객체입니다. View에서 출력할 데이터를 담아서 전달됩니다.
View
ㅡ Controller에서 생성된 Model을 출력하기 위한 템플릿 역할을 합니다.
Controller
ㅡ 클라이언트의 요청을 받아 Model 객체를 생성하고, 생성된 Model을 View에 전달합니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[REST API]
<주요 특징>
1. Stateless: 서버는 클라이언트의 이전 요청에 대한 정보를 저장하지 않습니다. 각 요청은 필요한 모든 정보를 포함해야 합니다.
2. Cacheable: 클라이언트는 응답을 캐시할 수 있으며, 캐싱된 응답은 향후 동일한 요청에 재사용될 수 있습니다.
3. Client-Server: 클라이언트와 서버는 독립적으로 구축되고 운영되며, 각각의 역할에 집중할 수 있습니다.
4. Layered System: 시스템은 여러 계층으로 구성될 수 있으며, 각 계층은 독립적으로 변경 및 발전할 수 있습니다.
5. Code on Demand (optional): 서버는 필요에 따라 클라이언트에 실행 가능한 코드를 제공할 수 있습니다.
직렬화(Serialization) : 객체를 저장, 전송할 수 있는 특정 포맷 상태로 바꾸는 과정
ㅡ Java에서의 직렬화는 객체를 Binary 형태로 변환하는 것
ㅡ Java에서 제공하는 직렬화 기능을 사용하지 않을 것을 강력히 권장하며, 대안으로 JSON 등의 포맷을 사용하는 것을 추천
역직렬화(Deserialization) : 특정 포맷 상태의 데이터를 다시 객체로 변환하는 것
JSON(텍스트 기반의 데이터 교환 형식)
<특징>
1. 가볍다.(전송할 데이터의 크기가 작습니다.)
2. 읽기 쉽다.(개발자들이 데이터를 쉽게 이해하고 디버깅할 수 있습니다.)
3. 언어 독립적이다.(다양한 시스템과 언어 간에 데이터를 쉽게 교환)
<사용 목적>
ㅡ 요청 본문 : 클라이언트가 서버에 데이터를 보낼 때, JSON 형식의 요청 본문을 사용하여 데이터를 전송
ㅡ 응답 본문 : 서버는 클라이언트에게 데이터를 반환할 때, JSON 형식의 응답 본문을 사용
@RequestBody는 HTTP 요청 본문의 내용을 자바 객체로 변환하는데 사용
@ResponseBody는 자바 객체를 HTTP 응답 본문으로 변환하는데 사용
ResponseEntity는 스프링 프레임워크에서 HTTP 응답을 표현하는 클래스
<특징>
1. 상태 코드 설정 : HTTP 응답의 상태 코드를 직접 설정할 수 있습니다.
2. 헤더 설정 : HTTP 응답의 헤더를 추가하거나 수정할 수 있습니다.
3. 본문 설정 : HTTP 응답의 본문을 직접 제어할 수 있습니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[3Tier-Architecture]
(컨트롤러 Layer계층)
ㅡ Controller는 웹 요청을 받아서 해당 요청을 처리할 Service를 호출하고, 그 결과를 다시 View에 전달하는 역할
(Controller는 클라이언트로부터의 입력을 처리하며, HTTP 요청에 대한 응답을 생성)
ㅡ Api 요청을 받음
ㅡ @Controller 등 뷰 탬플릿 영역
ㅡ @Filter, @Controller Advice, 인터셉터 등 외부 요청과 응답에 대한 전반적인 영역
(서비스 Layer계층)
ㅡ Service는 비즈니스 로직을 수행하는 역할
(Service는 Repository를 사용하여 데이터에 접근하고, 그 결과를 다시 Controller에 전달)
(Service는 보통 여러 개의 Repository를 사용하여 데이터를 처리)
ㅡ 트랜잭션, 도메인 기능 간의 순서 보장
ㅡ (Controller + Dao)의 중간 영역
ㅡ @Transactional이 사용되어야 하는 영역
(리포지토리 Layer계층)
ㅡ Repository는 데이터에 접근하는 역할
(Repository는 데이터베이스나 파일, 메모리 등의 다양한 데이터 저장소에 접근하는 기능을 제공)
(Repository는 보통 DAO(Data Access Object)로 불리기도 함)
ㅡ DB에 접근하는 영역
ㅡ Dao의 영역
(Dtos)
ㅡ Request 데이터를 받음
ㅡ 계층 간의 데이터 교환을 위한 객체 영역
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[설계 방식 비교]
(MVC 설계 방식)
1. @Controller ㅡ model객체 데이터를 담은 view를 반환
2. 사용자가 볼 '화면'에 대해 응답
(REST API 설계 방식)
1. URI와 HTTP Method를 이용
2. @Restcontroller ㅡ ResponseEntity로 감싸서 JSON형태로 객체 데이터를 반환
(@Controller + @Responsebody) HttpmessageConverter가 동작
3. 사용자가 볼 '데이터'에 대해 응답
4. 클라이언트 ㅡ Ajax를 사용하여 비동기 처리
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[REST API 관련 어노테이션]
@RequestMapping
HTTP(All) = 요청 메서드와 URL매핑 함께 지정
CRUD
[Create]
@PostMapping
HTTP(Post) = 리소스 생성
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[Read]
@GetMapping
HTTP(Get) = 리소스 조회
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[Update]
@PutMapping
HTTP(Put) = 리소스 갱신
@PatchMapping
HTTP(Patch) = 리소스 일부 갱신
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
[Delete]
@DeleteMapping
HTTP(Delete) = 리소스 삭제
