16 - 3. Spring - Spring MVC

Spring MVC

데이터 (Model) + 화면 (View) 를 연결해주는 Controller

• Web Application의 다양한 구성 요소가 역할을 분담하여 동작한다

• 이 구조는 특히 동적 웹 페이즈를 처리하는데 중요한 역할을 한다

• 동적 웹 페이지를 만들기 위해선 반복전인 템플릿 (View Template)과 데이터 (Model)이 필요하다

  • View Template: 반복적으로 사용하는 HTML “틀”

  • Model: 실제 데이터

  • View: 사용자가 최종적으로 보게되는 동적 웹 페이지이다

    MVC의 동작 원리

  • Controller가 사용자의 요청을 처리하고, Model을 조회하거나 조작한 후, 그 결과를 View Template에 반영하여 웹 페이지를 생성 후 반환하는 방식으로 동작한다

- Controller: 사용자의 요청을 받고, 로직을 수행한 후, 결과를 반환한다
    - 어떤 URL, Method인지만 알면 된다
- Model: DB와의 연동을 통해 데이터를 조회하거나 수정한다
- View: 데이터를 포함한 HTML을 생성하고 사용자에게 보여준다
    - HTML로 정의해둔다

Tomcat + Spring 의 구조

• Tomcat: 자바 기반의 WAS (Web Application Server)

💡

Tomcat이란?

• Web Server와 연동하여 실행할 수 있는 자바 환경을 제공하고, 관리 도구를 이용해서 설정을 변경할수도 있으며, XML 파일을 편집해서 설정할 수도 있다

• Tomcat을 사용해 동적인 데이터 처리를 가능하게 해준다

  • DB 연결, 데이터 조작, 다른 응용프로그램과 상호작용 등…
  • Port는 8080을 사용한다

• 동적인 웹을 만들기 위한 Web Container (Servlet container)라고 부른다

• 웹 서버에서 정적으로 처리해야할 데이터를 제외한, JSP, ASP, PHP 등을 Tomcat에게 전달한다

JAR = Tomcat + Spring

• JAR (Java Archieve): Spring Boot의 Application은 JAR 파일로 패키징 될 수 있으며, 이때 내장된 TomCat이 함께 포함되어 실행된다.
• 즉, 외부 Tomcat이 필요하지 않으며, JAR 파일을 실행한다면 Spring Application과 Tomcat서버가 한번에 구동된다 = Tomcat의 Version을 신경쓸 필요가 없다
  • Docker의 구동 원리라고 생각하면 편하다, Tomcat이 Base Image인 셈이다

WAR = Java | Spring

• Java Application
  • WAR 파일로 패키징 되며, 이 WAR 파일은 외부의 Tomcat과 같은 WAS에서 실행된다
  • 즉, Application과 Tomcat이 별도로 존재하여 Application은 Tomcat이 제공하는 환경 위에서 동작한다.
• Spring
  • WAR 파일로 패키징되며, 이때 역시 Tomcat 서버는 외부에 존재한다.
• WAR의 단점
  • Tomcat version이 다르다면 동작이 안될수도 있다
    • 내장 Tomcat과 달리 매번 확인해야하는게 번거로울수도 있다

Tomcat + Spring의 실제 동작 과정

1. Request: 수많은 요청들을 Connection Queue에 적재한다
2. Processing: Tomcat이 요청을 ServletRequest로 변환 후, Spring의 DispatcherServlet에 전달한다
3. Response: Spring은 요청을 처리한 후, DispatcherSerlvet의 결과를 사용자에게 반환한다

상세 구조를 살펴보자

• Container: 객체를 관리하는 주체

  • 두가지가 있다
    • Spring Container
      • 두가지가 있다
        • Servlet WebApplicationContext
        • Root WebApplicationContext
    • Servlet Container
      • Servelt Container는 위에 언급했듯이 Tomcat이다

• Spring의 동작 원리는 A + B (1 + 2)

  • A: Tomcat의 Servlet Container를 통해 유저 요청에 따라 Servlet을 할당한다

    • Servlet 객체는 Singleton이다
      • Singleton: Stateless & Thread-safe

  • B: Spring의 Spring Container를 통해 DispatcherServlet 요청에 따라 Spring Contorller를 할당한다

    • Spring Container = Servlet WebApplicationContext + Root WebApplicationContext

      • Spring Bean도 Spring Container로 관리되며 2개 타입의 ApplicationContext로 나뉜다
        1. Servlet WebApplicationContext: Servlet에서만 이용되는 Bean에 대한 Context
           1. DispatcherServlet이 직접 사용하는 Controller를 포함한 웹 관련 Bean 등록
           2. ex.) @Controller, HandlerMapping, …
        2. Root WebApplicationContext: Spring어디서든 이용되는 Bean에 대한 Context
           1. 서비스 계층이나 DAO 를 포함한 웹 환경에 독립적인 Bean 등록
           2. @Service, @Repository, …
      💡

      DispatcherServlet이란?

      HTTP Protocol로 들어오는 모든 요청을 가장 먼저 받아, 적합한 Controller에 위임해주는 Front Controller이다

    • Client로 부터 어떠한 요청이 오면 → Servlet Container (ex. Tomcat)이 받아 모든 요청을 → Front Controller (DispatcherServlet)에게 전달 → DispatcherServlet이 공통적인 작업을 먼저 처리함 → 해당 요청을 처리해야하는 Controller를 찾아서 작업을 위임한다

    • 장점:

      • DispatcherServlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링 해주고, 공통 작업을 처리하면서 상당한 편리함을 제공한다

Spring MVC의 실제 구조

1. Request: 사용자의 요청이 DispatcherServlet (Fornt Controller)으로 전달된다
   1. 요청을 받고, Spring에게 처리를 위임한 뒤, 응답을 반환한다
      1. DispatcherServlet의 구현체들: Handler Mapping & Handler Adapter
2. Handler Mapping: 요청에 해당하는 처리 메서드가 존재하는지 검색해본다
   1. Handler Adapters를 모두 순회하며 적합한 Handler Adapter를 찾는다
3. Handler Adapter: Controller의 로직을 수행할 수 있도록 돕는다
4. Controller: 요청을 받아, 실제 처리 뒤, 응답을 반환한다
   1. 여기에서 처리한 모든 응답은 Front Controller 로 반환된다
      1. 어떤 타입으로 반환할지 결정하는 주체가 @ResponseBody 이다
   2. 반환 가능한 타입에는 HTML과 Web Data (JSON)이 있다
      1. HTML: View를 반환한다 = View Template + Model
         1. View Resolver를 사용한다
      2. Data (JSON): Model을 반환한다
         1. MessageConverter를 사용한다
5. View Resolver: 처리된 데이터를 이용한 적절한 View를 선택한다
6. Model: View에서 보여줄 데이터를 준비한다
7. View: 최종 HTML 페이지를 반환한다
8. Response: 사용자가 요청한 페이지를 볼 수 있게 반환한다