Post

[Spring] 4. MVC 패턴

MVC 패턴이란?


  • 하나의 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller) 라는 세 가지 역할로 구분하는 소프트웨어 디자인 패턴


이 패턴의 핵심 목표는 ‘관심사의 분리(Separation of Concerns)’다.
즉, 사용자에게 보여주는 화면(View)과 데이터를 처리하는 비즈니스 로직(Model)을 서로 분리하여, 애플리케이션을 더 유연하고 유지보수하기 쉽게 만드는 것이다.



MVC의 3가지 구성 요소


각 구성 요소는 명확한 책임을 가지며, 서로에게 미치는 영향을 최소화하도록 설계된다.

1. 모델 (Model)

  • 역할: 애플리케이션의 데이터비즈니스 로직을 담당하는 부분.
  • 책임:
    • 애플리케이션이 다루는 데이터 그 자체(사용자 정보, 상품 정보 등)를 담고 있다.
    • 데이터를 변경하고 처리하는 규칙, 즉 비즈니스 로직을 구현한다.
    • 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.


스프링 아키텍처에서는 Service 계층과 Repository 계층, 그리고 DTO나 Entity 같은 데이터 객체들이 바로 모델(Model)에 해당한다. 모델은 뷰나 컨트롤러에 대해 아무것도 알지 못한다.


2. 뷰 (View)

  • 역할: 사용자에게 보여지는 UI(사용자 인터페이스)를 담당하는 부분.
  • 책임:
    • 모델이 처리한 데이터를 받아 사용자에게 보여주기 위한 화면을 렌더링한다.
    • 사용자가 보게 될 결과물을 생성하는 일 외에는 다른 로직을 가져서는 안 된다.


스프링에서는 Thymeleaf, JSP 같은 템플릿 엔진이 렌더링한 HTML 페이지가 전통적인 뷰에 해당한다. RESTful API에서는 모델의 데이터를 JSON이나 XML 형태로 변환하여 보여주는 것도 뷰의 한 형태로 볼 수 있다.


3. 컨트롤러 (Controller)

  • 역할: 모델과 뷰 사이를 연결하는 중재자 또는 다리 역할.
  • 책임:
    • 사용자의 입력(HTTP 요청)을 받아, 어떤 모델을 사용하여 처리할지 결정한다.
    • 모델을 업데이트하도록 지시하고, 처리된 결과를 다시 모델로부터 받는다.
    • 모델의 처리 결과를 어떤 뷰에 전달하여 화면에 표시할지 선택한다.


스프링에서는 @Controller 어노테이션이 붙은 클래스가 이 역할을 수행한다. 컨트롤러는 모델이나 뷰에 대해 직접적인 정보를 알지 못하고, 오직 둘 사이의 흐름만 제어한다.



스프링 MVC에서의 동작 흐름


스프링 MVC 프레임워크는 이 MVC 패턴을 매우 체계적으로 구현하고 있다.

  1. 사용자의 모든 요청은 가장 먼저 디스패처 서블릿(Dispatcher Servlet)에 도착한다.
    디스패처 서블릿은 모든 요청을 처리하는 프론트 컨트롤러(Front Controller) 역할을 한다.

  2. 디스패처 서블릿은 요청된 URL을 보고, 이 요청을 처리할 @Controller를 찾아 작업을 위임한다.

  3. @Controller는 요청을 처리하기 위해 Service(Model)를 호출하여 비즈니스 로직을 실행시킨다.

  4. Service는 로직 처리 결과를 @Controller에 반환한다.

  5. @Controller는 서비스 결과를 바탕으로, 사용자에게 보여줄 View의 이름과 데이터를 디스패처 서블릿에 알려준다.

  6. 디스패처 서블릿은 해당 View를 찾아 사용자에게 최종 응답을 보낸다.

This post is licensed under CC BY 4.0 by the author.