[Spring] Spring MVC

※ Spring MVC 발표 자료입니다! 

 

Spring MVC 란?

ChatGPT - 한줄로 정리할 수 있을까 싶어 GPT에게 물어봤습니다ㅎ

 

Spring 프레임워크 중에 웹 계층을 담당하는 모듈 중 하나로 정식 명칭은 Spring Web MVC 입니다.

💡 Spring MVC는 Servlet API위에서 동작하며 Model, View, Controller 세가지 구성요소를 사용해 클라이언트의 다양한 요청을 처리하고 단순 텍스트 형식부터 REST 형식, View 형식의 응답을 할 수 있도록 편리하게 구성된 프레임워크입니다.

 

 

Spring MVC가 어떤 방식으로 개발자를 편하게 해줬는지 자세히 알아보기 위해 등장 배경과 동작 방식을 중심으로 발표를 진행하겠습니다.

 

등장 배경

 

Spring MVC가 있기 전에는 HTML 코드에 JAVA 코드를 넣어 동적 웹 페이지를 생성하는 JSP와 서블릿만을 이용하여 웹서비스를 개발했다고 합니다.

 

 

 

해당 코드가 바로 JSP 템플릿 엔진을 사용하여 동적인 화면을 구성하는 방식입니다. HTML코드와 Java 코드가 복잡하게 얽혀있어 얼핏봐도 유지보수가 굉장히 힘들어 보이는 코드입니다.

→ 데이터를 조회하는 코드와 같은 비즈니스 로직이 JSP에 노출되며 뷰가 너무 많은 역할을 가지게된다.

→ 변경 주기가 다른 요소 (뷰 + 비즈니스 로직)가 강하게 결합되어 있어 화면이 변경되면 비즈니스 로직도 수정해야하는 변경에 취약한 형태가 된다.

 

 

1. MVC 패턴 적용

이러한 문제를 해결하기위해 추가된 개념이 MVC 패턴입니다.

 

출처 : 김영한 spring web mvc 강의

 

MVC는 Model-View-Controller의 약자로, 합쳐져 있던 뷰 로직과 비즈니스 로직을 세가지 레이어로 나누어 관리하는 패턴입니다.

 

클라이언트의 호출이 Controller를 통해 들어오면 그에 대한 비지니스 로직을 수행하고 그 결과를 Model에 담아서 View로직으로 전달해줍니다.

 

아래 코드가 Servlet을 상속받아 구현한 Controller 레이어로 model 역할을 해줄 servletRequest에 데이터를 담아 view로 전달해주는 것을 확인할 수 있습니다.

RequestDispatcher은 forward라는 메서드를 통해 인자로 받은 viewPath 경로의 jsp파일로 request와 response를 옮기는 기능을 수행합니다.

Controller

 

이후 View에서는 전달받은 Model을 사용하여 화면을 렌더링한후 클라이언트에게 전달해주는 형태가 되었습니다.

View

✅ 이렇게 MVC 패턴으로 레이어를 나눈 덕분에 비즈니스 처리 로직과 사용자 인터페이스를 명확하게 구분하게되면 각자가 맡은 일에만 집중할 수 있으며 느슨한 결합으로 유연성과 확장성, 그리고 유지보수의 편리성을 얻을 수 있습니다.

 

 

2. Front Controller 패턴 등장

하지만 위의 코드에도 아쉬운 점이 있습니다.

Controller코드를 다시 살펴보면 박스 친 비즈니스 로직 부분을 제외하고 서블릿을 이용하기 위해 기본적으로 명시해야하는 코드들이 존재한다는 것입니다.

 

 

Boilderplate 코드들 (서블릿을 사용하기 때문에 호출되는 코드들)

• 포워드 관련 코드

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

 

• ViewPath( prefix, seffix ) 코드

String viewPath = "/WEB-INF/views/new-form.jsp";
// prefix : /WEB-INF/views/
// seffix : .jsp

 

• 사용하지 않는 매개변수 호출

HttpServletRequest request, HttpServletResponse response

모든 컨트롤러 마다 해당 코드들이 존재한다면 불필요한 중복 코드들이 늘어날 것입니다.

 

 

이 문제를 보완하고자 프론트 컨트롤러(Front Controller) 패턴이 도입되었습니다. 비즈니스 로직을 처리하기전에 먼저 호출되어 공통 기능을 처리하기위한 프론트 컨트롤러를 두는 것입니다.

기존 구성

프론트 컨트롤러

URL마다 서블릿을 생성되었던 기존의 구성에서 하나의 서블릿이 모든 요청을 받고 필요한 컨트롤러를 호출해 주는 구성으로 변경되며 나머지 컨트롤러는 서블릿 라이브러리를 사용하지 않아도 되는 일반적인 자바 코드로만 구성된 객체(POJO)가 되었습니다.

 

 

→ 덕분에 WAS와 서블릿과의 결합력을 낮출 수 있어졌지만 Spring 프레임워크와의 결합력이 높아지겠죠

 

 

✅ Spring MVC에서 이 프론트 컨트롤러 역할을 하는 것이 바로 프레임워크의 핵심인 Dispatcher Servlet입니다.

 

Dispatcher Servlet이 단순히 중간 매개 역할만 해주는 것이 아니라 클라이언트 요청을 쉽게 사용할수 있도록 가공하고 공통을 로직들을 처리해주어 개발자가 비즈니스 로직에만 집중할 수 있게 되었습니다.

예외가 발생하였을 때 요청을 일관된 방식으로 처리하는 것도 프런트 컨트롤러인 디스패처 서블릿이 담당하고 있습니다.

 

 

 

그렇다면 Dispatcher Servlet은 우리가 만들어둔 컨트롤러 중 어떻게 적합한 컨트롤러를 찾아 위임해 주는 것일까요? Dispatcher Servlet에 동작에 대해 좀 더 알아보겠습니다.

 

Dispatcher Servlet

서블릿을 상속받은 구현체이며 모든 URL 패턴에 매핑되어 (urlPatterns=”/”), HTTP 프로토콜로 들어오는 요청을 제일 먼저 받아 작업을 수행하게 됩니다.

 

요청(Request)을 받으면 필요한 공통 처리를 한 후, 알맞는 Handler로 요청을 보낸 후(Dispatch) 실행 결과를 Http Response형태로 만드는 역할을 합니다.

여기서 Handler는 로직을 처리하기 위해 개발자가 구현한 각각의 controller 메소드를 말합니다.

 

 

요청에 적합한 처리를 하기 위해 Handler Mapping, Handler Adapter, View Resolver 인터페이스 전략을 사용합니다. 각각의 구현체는 Spring Configuration를 통해 빈으로 것을 받아 동작하게 됩니다.

• Handler Mapping : 핸들러들의 매핑 정보 저장
• Handler Adapter : 핸들러를 호출하고 결과를 반환
• View Resolver : 요청에 적합한 View로 렌더링

 

각각의 인터페이스들이 어떻게 사용되는지 코드와 함께 살펴보겠습니다. 아래 코드는 DispatcherServlet의 주요메소드인 doDispatch의 일부 입니다.

 

클라이언트로 요청이 들어오면 DispatcherServlet이 접수한뒤 요청을 위임하기 위해 doDispatch 메소드를 실행합니다.

 

1.  getHandler를 호출하여 handleMapping들 중 요청을 처리할(request의 URL과 매칭되는) handler가 있는지 확인하고 꺼내옵니다.

: 이때 handleMapping은 컨트롤러 빈을 파싱하여 hash map으로 관리합니다.

 

2. 적절한 handler를 찾으면 그에 맞는 HandlerAdapter를 탐색하여 요청을 위임할 어뎁터를 꺼내옵니다.

 

3. HandlerAdapter가 handler에게 요청을 위임하고 요청을 처리하게 됩니다.

: 이때 요청의 결과로 ModelAndView(model 과 view가 wrapping된 객체)를 반환합니다. 반환된 객체는 적절한 viewResolver에 의해 model이 렌더링 된 view를 구성하여 클라이언트에게 응답하게 됩니다.

@Controller면 ModelAndView를 반환하고 @RestController면 null을 반환하게 됨으로 View가 렌더링되는 과정은 생략하고 반환된 ResponseEntity를 HttpEntityMethodProcessor가 MessageConverter를 사용해 응답 객체를 직렬화한 후 응답하게 됩니다.

 

 

 

❗️ 인터페이스 전략을 사용하는 이유는 컨트롤러 구현방식이 다양하기 때문입니다. 스프링이 인터페이스를 다양하게 구현하였고 어댑터 패턴을 적용해 두었기때문 구현방식에 상관없이 요청에 위임 할 수 있게 된것입니다.
즉, DispatcherServlet 코드 변경 없이 원하는 기능을 쉽게 변경하거나 확장 가능하다는 것입니다.

 

handleMapping 구현체

BeanNameUrlHandlerMapping // 빈 이름이 URL과 동일한 핸들러 찾기 @Component(”/v1/post”)

ControllerBeanNameHandlerMapping // 빈 이름이 URL 이름과 동일한 핸들러 찾기 

SimpleUrlHandlerMapping // 프로퍼티에 등록된 매핑정보에서 핸들러 찾기

RequestMappingHandlerMapping // @RequestMapping 어노테이션 기반 핸들러 찾기 @Controller

HandlerAdapter 구현체

RequestMappingHandlerAdapter // @RequestMapping 어노테이션을 사용

HttpRequestHandlerAdapter // HttpRequestHandler 인터페이스 처리

SimpleControllerHandlerAdapter // controller 어노테이션 처리

 

handle는 여러 구현체를 동시에 사용할 수 있습니다. 하나의 구현체가 이상적이지만 2개 이상의 핸들러 매핑이 등록 되었 URL이 중복 매치될 경우 order 프로퍼티를 통해 우선순위가 높은 순서대로 구현체 전략에 따라 요청을 처리합니다.

구현체의 order 출력창 - 출처 :  https://bellog.tistory.com/m/219

 

order이 가장 작은 RequestMapping 구현체가 가장 높은 우선순위를 갖게되며 해당 방식이 우리가 가장 많이 사용하게되는 어노테이션을 이용하여 빈을 등록하는 방식입니다.

 

 제공되는 것 외에도 인터페이스만 구현해서 DispatcherServlet에 등록하면 나만의 컨트롤러를 만들 수도 있지만 거의 없는 상황이며 대부분 편리한 어노테이션 기반의 방식을 사용합니다.

 

 

동작 흐름을 다음과 같이 도식화 해볼 수 있겠네요. 디스패처 서블릿은 길잡이를 해주며 모든 역할을 위임하게 됩니다.

 

✅ DispatcherServlet 요약

 클라이언트로부터 어떠한 요청이 오면 Tomcat과 같은 서블릿 컨테이너가 요청을 받게 된다. 그리고 이 모든 요청을 먼저 프런트 컨트롤러인 디스패처 서블릿이 받게 된다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 세부 컨트롤러를 getBean()으로 가져오고, 정해진 메서드를 실행시켜 작업을 위임한다.

앞서 설명들인 동작이 매우 복잡해보이지만 Spring MVC가 역할을 잘 분리하고 다양한 인터페이스를 사용해 규격화해 놓았기 때문에 유연하고 확정성 있게 웹 애플리케이션을 설계할 수 있습니다.

 

 

개발자는 웹서비스를 위해 핸들러(요청 처리 로직)만 신경쓰면 되게 된것입니다! 스프링 프레임워크가 도입돼서 정말 다행이라는 생각이 다시 한번 하게되었습니다.🙃

 

 

 

 

Ref.

https://www.youtube.com/watch?v=9Tmzt6Q9WI8&ab_channel=뉴렉처

https://bellog.tistory.com/m/219

[김영한] Spring MVC Part1

---

그 외

• 서블릿 : WAS안에 요청의 의미있는 로직을 추출해주는 컴포넌트
  • WAS안에 서블릿 컨테이너가 있고 서블릿의 생명주기를 관리한다.
  • 서블릿 컨테이너는 동시 요청에 대한 멀티 스레드를 지원한다.
  • 서블릿은 싱글톤으로 관리한다. → 고객의 요청에 따라 계속 생성, 삭제하는 것은 비효율적. (Request와 Response는 객체는 계속 생성되는 것이 맞음)
• MVC 구성
  • Model : 데이터를 관리하고 비즈니스 로직을 처리하는 구간
  • View : 사용자 인터페이스가 표현되는 구간. 모델로 부터 전달 받은 데이터를 사용자에게 보여주기만 할뿐 어떤 데이터가 넘어왔는지는 관심을 가지지 않는다.
  • Controller : Model과 View를 연결해주는 구간. View를 통해 사용자 요청이 들어오면 Controller가 해당 요청을 Model한테 알려 비즈니스 로직을 처리하고, 요청한 데이터를 전달한다.
• MVC 패턴의 단점
  • → 시스템 규모가 커질수록 model과 view의 의존도가 높아져서 관가 힘들어지는 상황이 생길 수 있다. 이를 보완하기 위한 MVP, MVVM 같은 디자인 패턴도 존재
• spring 컨테이너
• DispatcherServlet 생성 시점 : 하나의 서블릿으로 톰캣이 실행되 서블릿 컨텍스트가 초기화하는 시점에 옵션에 따라 lazy load 혹은 pre loading 방식으로 생성된다.
  • https://velog.io/@suhongkim98/DispatcherServlet과-스프링-컨테이너-생성-과정
• DispatcherServlet 싱글톤

 

 

 

잘못된 정보가 있다면 댓글을 통해 알려주세요. 감사합니다.