[Spring]Spring MVC

Spring MVC - Controller + Service

[Spring]Spring MVC

[Spring]Spring MVC - Controller 클래스 구조 생성 및 설계

[Spring]Spring MVC - Controller 클래스에 핸들러 메서드(Handler Method) 구현

[Spring]Spring MVC - Controller 클래스에 ResponseEntity 적용

[Spring]Spring MVC - Controller 클래스에 DTO 적용

[Spring]Spring MVC - DTO 유효성 검증(Validation)

[Spring]Spring MVC - DI를 통한 API 계층 ↔ 서비스 계층 연동

[Spring]Spring MVC - 매퍼(Mapper)를 이용한 DTO 클래스 ↔ 엔티티(Entity) 클래스 매핑

[Spring]Spring MVC - @ExceptionHandler를 이용한 예외처리

[Spring]Spring MVC - @RestControllerAdvice를 이용한 예외처리

[Spring]Spring MVC - 비즈니스로직 예외 던지기(throw) 및 처리

[Spring]Spring MVC - Custom Exception을 이용한 클라이언트 출력

 

Spring Data JDBC

[Spring]JDBC(Java DataBase Connectivity)

[Spring]SQL Mapper vs. ORM

[Spring]Spring Data JDBC, Spring Data JDBC 사용법

[Spring]Spring Data JDBC - 도메인 엔티티&테이블 설계

[Spring]Spring Data JDBC - 도메인 엔티티 클래스 정의

[Spring]Spring Data JDBC - Service, Repository 구현

 

Spring Data JPA

[Spring]JPA(Java Persistence API)

[Spring]JPA - Entity ↔ DB Table Mapping

[Spring]JPA - Entity ↔ Entity Mapping

[Spring]Spring Data JPA - 데이터 액세스 계층 구현

[Spring]ORM, Hibernate, JPA, Spring Data JPA

[Spring]트랜잭션(Transaction)

[Spring]트랜잭션(Transaction) - @Transactional

 

이전 글에서 스프링의 모듈 구조에 대해 본 적이 있다.

 

출처: https://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/html/overview.html

2. Introduction to Spring Framework

그림에서 보듯이 모듈 중에는 웹(Web) 계층을 담당하는 몇 가지 모듈이 있고,

 

이중 서블릿(Servlet) API를 기반으로 클라이언트의 요청을 처리하는 모듈이 있는데 이 모듈이 바로 spring-webmvc이다.

 

---

 

• 서블릿(Servlet)?

서블릿은 클라이언트의 요청을 처리하고, 그 결과를 반환하는 자바 웹 프로그래밍 기술이다.

 

조금 더 구체적으로는 클라이언트의 요청에 대한 결과를 동적으로 전송하는 역할을 하는 자바 클래스 파일이라고 할 수 있다.

 

아파치 톰캣(Apache Tomcat)과 같은 서블릿 컨테이너에서 실행되며, 보안 적용이 쉽다는 장점이 있다.

 

스프링 MVC 내부에서는 서블릿을 기반으로 웹 애플리케이션이 동작한다.

---

위와 같은 서블릿을 이용하는 spring-webmvc 모듈이 스프링 MVC이며, 스프링 MVC 프레임워크라고도 불린다.

 

이름에서 볼 수 있듯이 Web 서버에 특화되어 만들어진 모듈이며, 개발자가 신경 쓸 영역을 많이 줄여준다.

 

따라서 기존의 스프링에 비해 깔끔하고 간편하게 개발이 가능해진다는 장점이 있다.

 

계속해서 스프링 MVC의 MVC패턴에 대해 알아보자.

 

선 요약하자면 MVC는 모델 - 뷰 - 컨트롤러(Model - View - Controller)의 약자로 소프트웨어 아키텍처 패턴이다.

 

MVC 패턴의 목적은 사용자 인터페이스로부터 비즈니스 로직을 분리해 개발 생산성을 높이는 것이며

 

사용자의 다양한 요청을 처리하고 요청에 맞는 응답을 할 수 있도록 하는 것이다.

 

• Model

모델은 데이터의 디자인을 담당하며,

 

앱이 클라이언트에게 응답으로 돌려주는 작업의 처리 결과 데이터를 모델이라고 부른다.

 

이때 클라이언트의 요청 사항을 구체적으로 처리하는 영역을 서비스 계층(Service Layer)이라고 하며, 

 

실제로 요청 사항을 처리하기 위해 Java 코드로 구현한 것을 비즈니스 로직(Business Logic)이라고 한다.

 

참고로 스프링 MVC는 위 그림에서 Presentation Layer(=API Layer)영역을 세분화 한 것이다.

 

참고: https://gnidinger.tistory.com/452

[Spring]아키텍처

 

• View

뷰는 실제로 렌더링(완성)되어 보이는 페이지를 담당한다.

 

조금 더 구체적으로는 위에서 살펴본 모델 데이터를 이용해 사용자에게 출력할 화면을 만드는 일을 한다고 보면 된다.

 

이렇게 생성된 화면은 웹 브라우저와 같은 클라이언트 애플리케이션이 출력한다.

 

스프링 MVC는 HTML, PDF, Excel, XML, JSON 등으로 출력하는 기능이 포함되어 있으며,

 

앞으로 알아볼 방식은 모델 데이터를 JSON 프로토콜 데이터로 변환하는 것이다.

 

---

• JSON(JavaScript Object Notation)?

JSON은 서버와 클라이언트 사이에서 데이터를 보낼 때 사용하는 양식이다.

 

일정한 패턴의 문자열을 생성해 내보내면 클라이언트는 그것을 사용하는 언어로 해석해 온전히 저장, 표시할 수 있게 된다.

 

즉, 자바스크립트로부터 파생되어 자바스크립트의 구문 형식을 따르지만, 언어 독립형 데이터 포맷이다.

 

장점으로는 

 

      - 프론트엔드 / 백엔드 영역의 명확한 구분에 의한 개발 및 유지보수의 편의성 

      - 프론트엔드 측에서 비동기 클라이언트 앱을 만들 수 있게 됨

 

등이 있다.

 

JSON의  기본 포맷은

{"korName":"아메리카노","engName":"Americano","price":3000}

과 같은  {"속성":"값"} (Attribute–Value Pairs) 형태로 이루어져 있으며,

 

자바 객체를 손쉽게 JSON으로 혹은 그 반대로 변환할 수 있다.

---

• Controller

컨트롤러는 클라이언트 측의 요청을 직접적으로 전달받는 엔드포인트이며, Model과 View를 연결하는 제어 로직을 담당한다.

 

즉, 클라이언트 측의 요청에 대해 Model 데이터가 만들어지면, 이 데이터를 View로 전달하는 역할을 한다고 볼 수 있다.

 

여기서 당연히 뷰로 전달된 데이터는 앞서 살펴봤던 JSON으로 변환돼 클라이언트로 전달된다.

 

이어서 살펴보겠지만, 먼저 대략적으로 스프링 MVC의 흐름을 살피면 아래와 같다.

 

• Client가 요청 데이터 전송 → Front Controller가 요청 데이터 수신 → 비즈니스 로직 처리 → Model 데이터 생성 
  → Controller에게 Model 데이터 전달 → Controller가 View에게 Model 데이터 전달 → View가 응답 데이터 생성

계속해서 스프링 MVC의 구성요소와 작동방식에 대해 조금 더 자세히 알아보자.

 

---

• DispatcherServlet

하나 위에 올린 그림을 보면 컨트롤러가 둘로 나눠진 것을 볼 수 있다.

 

컨트롤러 중에서도 맨 앞에서 유저의 요청을 받고 관리하는 컨트롤러를 프론트 컨트롤러라고 하는데,

 

DispatcherServlet 객체가 이 역할을 하게 된다.

 

본격적으로 로직에 들어가기 전에 요청에 대한 선처리 작업을 수행하며 HTTP Request를 처리할 컨트롤러를 지정한다.

 

즉 DispatcherServlet은 컨트롤러를 지정하는 일종의 Super Controller 역할을 한다고 볼 수 있다.

 

이후 넘겨받은 결괏값을 View에게 전달하여 알맞은 응답을 생성하는데, 시작과 끝을 담당하는 역할이라 볼 수도 있다.

 

참고로 스프링에선 프론트 컨트롤러는 DispatcherServlet이라고 하고 컨트롤러는 핸들러라고 말한다.

 

또한 위 그림처럼 앞쪽에 처리하는 컨트롤러를 두는 패턴을 프론트 컨트롤러 패턴이라고 말한다.

 

• Handler Mapping(@RequestMapping)

@GetMapping(”/coffee”)과 같은 HTTP Request Method(GET, POST 등)와 매핑 URL을 기준으로

 

어떤 핸들러 객체를 사용할지 결정하는 객체이다.

 

DispacherServlet은 하나 이상의 핸들러 매핑을 가질 수 있다.

 

• Handler Adapter

다른 프레임워크의 핸들러를 Spring MVC에 통합하기 위해서 사용된다.

 

전달받은 Controller 정보를 기반으로 해당 Controller의 Handler 메서드를 호출(@RequestMapping)하며,

 

쉽게 말해 매핑된 핸들러를 실제로 실행하는 역할을 한다.

 

• Controller(=Handler)

위에서도 살펴봤지만 짧게 부가 설명을 한다.

 

컨트롤러는 DispatcherServlet에 의해 배정되며 HTTP Request를 처리하고

 

필요한 데이터를 뽑아 Model에 저장, 결과를 DispatcherServlet에게 전달한다.

 

즉, 컨트롤러는 해당 요청을 처리하는 로직을 담고 있으며 필요한 로직을 호출한다.

 

또한 HTTP Request에 따라서 HTTP가 보여줄 View Name을 지정하는데, 필요하다면 직접 View를 반환할 수도 있다.

 

• View Resolver

Controller가 리턴한 모델 데이터와 view 이름을 기반으로 Controller 처리 결과를 생성할 뷰를 결정한다.

 

모델 데이터를 기반으로 view를 렌더링 해 반환하며, 여기서 그려지는 view는 그대로 유저에게 반환된다.

---

그림을 다시 가져오자.

 

이제 구체적으로 스프링 MVC가 요청을 처리하는 방식에 대해 살펴보자.

 

1. 클라이언트의 요청이 DispatcherServlet에 전달
2. DispatcherServlet이 요청을 처리할 Controller에 대한 검색을 HandlerMapping 인터페이스에게 요청
3. HandlerMapping이 매핑된 핸들러 객체를 DispatcherServlet에게 리턴
   
   
   • 핸들러 객체는 해당 핸들러의 핸들러 메서드(요청 처리 메서드, Controller 클래스에 구현) 정보를 포함
4. DispatcherServlet이 HandlerAdpater에게 실제 요청을 처리할 Handler 메서드 호출을 위임
5. HandlerAdapter는 전달 받은 Controller 정보를 기반으로 해당 Controller의 Handler 메서드를 호출
6. Handler 메서드가 비즈니스 로직 처리 후 리턴 받은 Model 데이터를 HandlerAdapter에게 전달
7. HandlerAdapter가 전달받은 Model 데이터와 View 정보를 DispatcherServlet에게 전달
8. DispatcherServlet이 전달 받은 View 정보를 ViewResolver에게 전달해서 View 검색 요청
9. ViewResolver가 View 정보에 해당하는 View를 찾아서 리턴
10. DispatcherServlet이 전달 받은 View 객체에게 Model 데이터를 넘겨주면서 응답 데이터 생성을 요청
11. View가 응답 데이터를 생성해서 DispatcherServlet에게 전달
12. DispatcherServlet이 View로부터 전달 받은 응답 데이터를 최종적으로 클라이언트에게 전달

DispatcherServlet이 가장 앞에 배치되어 많은 일을 하는 것처럼 보이지만

 

실제 요청에 대한 처리는 다른 구성 요소들에게 위임하고 있다는 것을 확인할 수 있다.