Spring - MVC, 서블릿

스프링 MVC

1. 스프링 MVC

M(모델)

- 평범한 자바 객체

- 도메인 객체 또는 DTO로 화면에 전달할 또는 화면에서 전달 받은 데이터를 담고 있는 객체

 

V(뷰)

- HTML, JSP, 타임리프..

- 데이터를 보여주는 역할. 다양한 형태로 보여줄 수 있음 (HTML, JSON, XML)

 

C(컨트롤러)

- 스프팅 @MVC

- 사용자의 입력을 받아 모델 객체의 데이터를 변경하거나, 모델 객체를 뷰에 전달

- 입력 값 검증, 입력 받은 데이터를 모델 객체로 변경, 변경된 모델 객체를 뷰에 전달

 

2. MVC 패턴의 장점

동시 다발적 개발

높은 결합도

낮은 의존도

개발 용이성

한 모델에 대한 여러 형태의 뷰를 가질 수 있음

 

3. MVC 패턴의 단점

코드 네비게이션이 복잡함

코드 일관성 유지에 노력이 필요함

높은 학습 곡선

 

서블릿

1. 서블릿 애플리케이션

 

서블릿

- 자바EE는 웹 애플리케이션 개발용 스펙과 API를 제공

- 요청 당 쓰레드를 만들거나, 풀에서 가져다가 사용 

- HttpServlet

 

서블릿 장점

- 빠르다

- 플랫폼 독립적

- 보안

- 이식성

 

서블릿 컨테이너

- 톰켓, 제티, 언더토

- 서블릿 스펙(웹 애플리케이션 개발 스펙과 API)을 준수하는 것들

- 세션 관리 

- 네트워크 서비스

- 서블릿 생명주기 관리 (init, destroy)

 

 

2. 서블릿 리스너와 서블릿 필터

 

서블릿 리스너

- 웹 애플리케이션에서 발생하는 주요 이벤트를 감지하고 각 이벤트에 특별한 작업이 필요한 경우에 사용할 수 있다.

- 서블릿 컨텍스트 수준의 이벤트, 세션 수준의 이벤트

 

서블릿 필터

- 들어온 요청을 서블릿으로 보내고, 또 서블릿이 작성한 응답을 클라이언트로 보내기 전에 특별한 처리가 필요한 경우에 사용할 수 있음

- 체인 형태의 구조

 

 

3. 서블릿에서 스프링에서 제공하는 IoC 컨테이너 연동하기

 

1) spring-mvc 의존성 추가

 

2) ContextLoaderListener 추가

- Application Context를 만듬.

- 서블릿 생명주기에 맞추어 Application Context가 실행되도록 함

 

3) 스프링 설정 파일 생성 및 위치 설정

- Application Context를 만들기 위해서는 스프링 설정 파일 필요

 

 

4. 서블릿에 스프링 MVC 적용하기

 

Servlet에서는 각 url 마다 서블릿을 매핑해줘야 함 -> 설정 코드가 길어지고 불편

따라서, 모든 요청을 FrontController가 받고, 핸들러에게 dispatch하는 방식으로 해결 가능

스프링이 이러한 것을 구현했음 (DispathcherServlet - 스프링MVC에서 가장 핵심적인 클래스)

 

웹 설정 없는 Application Context와 웹 설정이 들어간 Application Context 를 계층적으로 구현함

Service 와 같은 것은 모든 곳에서 사용 가능하도록 하기 위해

(경우에 따라 설정하는 것으로, 굳이 계층적으로 구현하지 않고 모든 설정이 들어가도록 해도 됨 -> 최근에는 더더욱 계층적으로 구현하지 않음)

 

(계층적으로 구현하지 않는다면 위의 3번 과정 삭제 후 진행)

1) DispathcherServlet 을 추가

2) 위와 같이 설정 파일 생성 및 위치 설정

3) 서블릿 매핑 설정 (/app/*)

4) Controller 작성

 

 

스프링 부트와 다른 점

- 이러한 방식은 서블릿 컨테이너가 먼저 작동하고 서블릿 애플리케이션이 동작

- 스프링 부트는 스프링 부트 어플리케이션이 먼저 작동하고, 내부적으로 서블릿 컨테이너가 동작

 

 

5. DispatcherServlet

 

HandlerMapping : 핸들러를 찾아주는 인터페이스

HandlerAdapter : 핸들러를 실행하는 인터페이스

HandlerExceptionResolver

ViewResolver

 

동작 순서

1. 요청을 분석한다. (로케일, 테마, 멀티파트 등)

2. (핸들러 매핑에게 위임하여) 요청을 처리할 핸들러를 찾는다.

3. (등록되어 있는 핸들러 어댑터 중에 ) 해당 핸들러를 실행할 수 있는 "핸들러 어댑터"를 찾는다.

4. 찾아낸 "핸들러 어댑터"를 사용해서 핸들러의 응답을 처리한다.

   4-1) 핸들러의 리턴 값을 보고 어떻게 처리할 지 판단한다.

     - ViewResolver가 뷰 이름에 해당하는 뷰를 찾아서 모델 데이터를 랜더링한다.

     - @ResponseEntity가 있다면 Converter를 사용해서 응답 본문을 만든다.

5. (부가적으로) 예외가 발생했다면, 예외 처리 핸들러에 요청 처리를 위임한다.

6. 최종적으로 응답을 보낸다.