CS
  • CS-Study
  • database
    • B-Tree와 B+Tree
    • DB JOIN
    • DB Lock
    • DB 트래픽
    • DBCP (DB Connection Pool)
    • Flyway
    • Message Broker
    • MySQL InnoDB 스토리지 엔진
    • MySQL 엔진 아키텍처
    • RDB와 NoSQL
    • Redis
    • SQL Injection
    • 스키마 (Schema)
    • Table Scan과 Index Scan
    • Apache Kafka
    • Key
    • 뷰 (View)
    • 인덱스
    • 정규화
    • RDBMS, NoSQL의 클러스터링/리플리케이션 방식
    • 트랜잭션(Transaction)
    • 트랜잭션의 격리성(Transaction Isolation)
    • 프로시저와 트리거
    • DB 정규화 (Normalization)
  • etc
    • MSA
    • REST, REST API, RESTful
    • SOLID 원칙
    • TDD (Test-Driven Development)
    • 서버리스
    • 컨테이너와 도커
  • java
    • Collections
    • Garbage Collection
    • Generic
    • JDBC
    • Java Virtual Machine(JVM)
    • Java Thread
    • Java8 vs Java11 vs Java17
    • 객체지향 프로그래밍 OOP (Object Oriented Programing)
    • Optional
    • RxJava(Reactive Programming)
    • 문자열(String & StringBuffer & StringBuilder)
    • Synchronized
    • Virtual Thread
    • Wrapper Class
    • Equals()와 Hashcode()
    • final
    • Jackson 라이브러리
    • 리플렉션(Reflection)
    • static class와 static method
    • 스트림(Stream)과 람다(Lambda)
    • 스프링 프레임워크에서 사용되는 디자인 패턴
    • 예외처리(Exception)
    • Java Annotation
    • 추상클래스와 인터페이스
  • network
    • 3-way handshake
    • 4-way Handshake
    • DHCP(Dynamic Host Configuration Protocol)
    • DMZ(DeMilitarized Zone)
    • DNS(Domain Name System)
    • HTTP Method
    • HTTP 버전 비교
    • HTTP status code
    • HTTP
    • IP Address
    • Mutiplexing & Demultiplexing
    • OSI 7계층
    • SOP, CORS
    • TCP와 UDP
    • XSS와 CSRF
    • gRPC
    • Stateless와 Connectionless
    • 라우터 Router
    • 로드밸런서(Load Balancer)
    • 브라우저에 URL입력시 네트워크 상 일어나는 일
    • 서브넷 마스크, 게이트웨이
    • 웹 소켓과 소켓 통신
    • 쿠키(Cookie)와 세션(Session)
  • operating-system
    • IPC (Inter Process Communication)
    • 인터럽트
    • TLB
    • 스레싱 Thrashing
    • Thread Pool, Fork-Join
    • Thread Safe
    • 프로세스
    • 가상 메모리
    • 데드락 (DeadLock, 교착 상태)
    • 동기/비동기 & 블로킹/논블록킹
    • 동기화(Synchronization)
    • 메모리 할당과 단편화
    • 뮤텍스와 세마포어, 모니터
    • 세그먼테이션과 페이징
    • 운영체제
    • 캐시 메모리
    • Context switching(문맥 교환)
    • 컴파일
    • 파일 시스템
    • 페이지 교체 알고리즘(Page Replacement Algorithm)
    • 프로세서 스케줄링 알고리즘
    • 프로세스 주소 공간
  • spring
    • @Transactional
    • AOP(Aspect-Oriented Programming)
    • DTO, DAO, VO, Entity
    • DispatcherServlet
    • Hibernate, JPA, Spring Data JPA
    • Ioc와 DI
    • JPA 연관관계 맵핑
    • N+1 Problem
    • ORM
    • Persistence Context
    • SQL Mapper vs ORM vs QueryBuilder
    • Servlet Filter와 Spring Interceptor
    • Servlet
    • Spring MVC와 Spring Boot
    • Tomcat
    • WebFlux
Powered by GitBook
On this page
  • DispatcherServlet이란?
  • 상속 구조(계층 구조)
  • 프론트 컨트롤러 패턴(Front Controller Pattern)
  • 어댑터 패턴(Adapter Pattern)
  • 디스패처 서블릿의 동작 과정
  • 디스패처 서블릿 설정 방법
  • Ref
  1. spring

DispatcherServlet

PreviousDTO, DAO, VO, EntityNextHibernate, JPA, Spring Data JPA

Last updated 1 year ago

DispatcherServlet이란?

  • 스프링 MVC가 사용하는 핵심 개념

  • HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러로 정의함

    • 클라이언트로부터 어떤 요청이 들어오면 서블릿 컨테이너가 요청을 받는데, 이때 공통된 작업은 디스패처 서블릿에서 처리하고, 이외 작업은 다른 세부 컨트롤러로 위임함

  • 과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했음

    • DispatcherServlet의 등장으로 애플리케이션으로 들어오는 모든 요청을 핸들링해주고 공통 작업을 처리하면서 web.xml의 의존을 낮출 수 있게 됨

상속 구조(계층 구조)

  • DispatcherServlet ➡ FrameworkServlet ➡ HttpServletBean ➡ HttpServlet ➡ GenericServlet ➡ Servlet

    public class DispatcherServlet extends FrameworkServlet {
    }
    
    public abstract class FrameworkServlet extends HttpServletBean {
    }
    
    public abstract class HttpServletBean extends HttpServlet {
    }
  • 디스패처 서블릿도 의 일종으로, HttpServlet을 상속함

프론트 컨트롤러 패턴(Front Controller Pattern)

  • 도입 배경

    • MVC 패턴 중 컨트롤러가 많아지고, 컨트롤러에서 공통으로 처리해야 하는 부분이 증가한다면 코드 중복이 발생함

      • 각 컨트롤러마다 공통 로직을 만들어야 했음

    • 프론트 컨트롤러 도입 후에는 공통 로직은 프론트 컨트롤러에서 처리하고, 각자 처리해야하는 로직은 각 컨틀롤러에 처리함

      • 공통의 관심사를 별도로 모으는 역할

  • 특징

    • 서블릿 하나로 클라이언트의 요청을 모두 받음

    • 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출함

    • 공통 처리 가능

    • 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 ➡ 프론트 컨트롤러가 나머지 컨트롤러를 직접 호출해주기 때문

    • 스프링 웹 MCV의 핵심으로, DispatcherServlet이 FrontController 패턴으로 구현됨

  • 도입 이후 처리과정

    1. 클라이언트 - HTTP 요청

    2. Front Controller - URL 매핑 정보에서 컨트롤러 조회 후 컨트롤러 호출

    3. Controller - ModelAndView 반환

    4. Front Controller - ViewResolver 호출

    5. ViewResolver - View*반환

    6. Front Controller - 클라이언트에 View 응답을 전달

어댑터 패턴(Adapter Pattern)

  • 도입 배경

    • 서블릿 컨테이너에서 요청이 오면 모두 디스패처 서블릿을 거쳐 세부 컨트롤러로 가는데, 각각의 세부 컨트롤러 인터페이스는 완전히 다른 인터페이스이기 때문에 서로 간의 호환이 불가능한 상태임

    • 이때 어댑터 패턴을 사용하면 기존 구조를 유지하면서 프레임워크의 기능을 확장할 수 있음

      • 기존에는 한 가지 방식의 인터페이스만 사용가능했지만, 어댑터 패턴을 이용하여 프론트 컨트롤러가 다양한 인터페이스를 처리할 수 있도록 함

  • 특징

    • 어댑터 패턴은 호환되지 않는 인터페이스들을 연결하는 디자인 패턴으로, 기존의 클래스를 수정하지 않고도 특정 인터페이스를 필요로 하는 코드에서 사용할 수 있게 도와줌

      • 어댑터용 인터페이스를 만들어 처리할 수 있는 컨트롤러를 판단하여 그 컨트롤러를 호출함

    • 스프링 MVC의 핸들러 어댑터(HandlerAdapter) 인터페이스가 바로 어댑터 패턴을 사용함

      • 스프링 MVC가 사용하는 어댑터의 이름이 컨트롤러 어댑터가 아니라 핸들러 어댑터인 이유는 컨트롤러 뿐만 아니라, 어댑터가 지원하기만 하면 어떤 것이라도 URL에 매핑하여 사용할 수 있기 때문

  • 도입 이후 처리과정

    1. 클라이언트 - HTTP 요청

    2. Front Controller

      • Handler Mapping 정보에서 핸들러 조회

      • 핸들러를 처리할 수 있는 Handler Adapter 조회

      • 핸들러 어댑터의 handle(handler) 호출

    3. Handler Adapter

      • handler(실제 Controller) 호출

      • ModelView 반환

    4. Front Controller - ViewResolver 호출

    5. ViewResolver - View 반환

    6. Front Controller - 클라이언트에 View 응답을 전달

디스패처 서블릿의 동작 과정

  1. DispatcherServlet으로 클라이언트의 웹 요청(HttpServletRequest)이 들어옴

  2. 웹 요청을 HandlerMapping에 위임하여 해당 요청을 처리할 Handler(Controller)를 탐색

  3. 찾은 Handler를 실행할 수 있는 HandlerAdapter를 탐색

  4. 찾은 HandlerAdapter를 사용해서 Handler의 메서드를 실행

  5. 이때 Handler의 반환값은 Model과 View임

  6. View 이름을 ViewResolver에게 전달하고, ViewResolver는 해당하는 View 객체를 반환함

  7. DispatcherServlet은 View 에게 Model을 전달하고 화면 표시를 요청하는데, 이때 Model이 null이면 View를 그대로 사용함

    • 반면 값이 있으면 View에 Model 데이터를 렌더링함

  8. 최종적으로 DispatcherServlet은 View 결과(HttpServletResponse)를 클라이언트에게 반환함

위 흐름은 @Controller 기준이고, @RestController의 경우 6, 7과정이 생략된다. 즉, ViewResolver를 타지 않고 반환값에 알맞는 MessageConverter를 찾아 응답을 작성한다.

디스패처 서블릿 설정 방법

디스패처 서블릿을 구현하는 방법에는 2가지가 있다.

  1. web.xml에 DispatcherServlet 선언 방법

    • xml에 DispatcherServlet을 선언하고 URI로 요청 경로를 매핑하여 사용할 수 있음

    • 표준 J2EE 서블릿 설정 예시

      <web-app>
      
          <servlet>
              <servlet-name>example</servlet-name>
              <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
              <load-on-startup>1</load-on-startup>
          </servlet>
      
          <servlet-mapping>
              <servlet-name>example</servlet-name>
              <url-pattern>*.form</url-pattern>
          </servlet-mapping>
      
      </web-app>
  2. DispatcherServlet 상속 후 @Webservlet 애노테이션 사용 방법

    @WebServlet(name = "helloServlet", urlPatterns = "/hello")
    public class HelloServlet extends DispatcherServlet {
    }
    • DispatcherServlet을 상속하여 @WebServlet 애노테이션에 urlPatterns를 지정하여 사용할 수 있음

    • @WebServlet 애노테이션을 사용하려면 Httpservlet을 상속해야 하는데 위에서 말했듯이 DispatcherServlet은 HttpServlet을 상속하기 때문에 서블릿 클래스에서 DispatcherServlet을 상속해도 문제 없음

Ref

서블릿 참고
서블릿
Spring DispatcherServlet(디스패처서블릿) 개념부터 동작 과정까지
스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술
[Spring] 📚 Dispatcher Servlet 이해하기
[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정
DispatcherServlet - Part 1
자바 어댑터 패턴은 어떻게 쓰일까?