MVC 패턴
Spring MVC 패턴이란 현개발 환경에서 스프링이 정말로 많이 쓰이는 이유 중 하나라고 생각한다. MVC 구조를 이해하고 내부 기능을 이해 하면서 이 강의를 듣기 전에 연습으로 개발해 봤었던 모든 과정들의 이유를 하나씩 배울 수 있었다.
시작하기에 앞서, MVC 패턴이란 새로운 기술도 아니고 특정 프로그램도 아닌 아키텍처 라고 이해 하는게 더 쉬울거 같다는 생각이 들었다.
MVC 패턴을 설명하기 위해서는 4가지의 추가적인 설명이 필요하다.
-
서블릿
-
서블릿 컨테이너와 서블릿 동작 방식
-
프론트 컨트롤러 패턴
-
Dispatcher Servlet
위에 있는 개념들이 잡히게 되면은 왜 MVC 패턴이 등장 했는지, 또 어떤 편리함을 제공하는지에 대해서 더 쉬운 설명이 가능 할것이다.
서블릿이란?
앞서 시리즈별로 작성하는 서블릿 포스팅을 보면은 서블릿과 관련된 자세한 내용을 확인 할 수 있다. 그리고 핵심을 요약해서 설명하자면은 보통 클라이언트와 웹간의 상호작용은 요청 과 응답 과정을 거치게 된다.
GET/PUT/POST 등 정말로 많은 차이점들이 존재하지만 요청과 응답 과정에서 공통적인 부분은 HTTP 통신으로 이루어진다는 것이다.
HTTP 통신과 관련된 포스트도 HTTP 포스트 작성된걸 볼 수 있지만 요청 과정에서는 HTTP 헤더와 바디에 내가 원하는 정보를 담아서 서버로 보내게 되고, 응답 과정에서는 똑같이 HTTP 헤더와 바디에 다른 정보를 가지고 클라이언트가 받게된다.
사실 서블릿 이전에 개발 환경을 경험해보지는 못했지만 원래는 백엔드 개발자가 위와 같은 HTTP 요청과 응답 메세지를 직접 해석하고 파싱하는 작업을 거쳤다고 한다. 예를 들어 GET 요청이면 GET 요청을 파싱하고 BODY 를 파싱하고 응답 과정이면 HTTP 상태 메세지와 함께 응답 내용을 보냈다.
그러나, 서블릿의 등장 이후로는 이 전에 개발자들이 HTTP 메세지를 분석하며 파싱하는 과정들을 넘어서 서블릿이 제공해주는 HTTP servlet request 메서드로 파싱 작업이 불필요 해졌고 개발자들은 오로지 비즈니스 로직에만 맞추어서 개발할 수 있는 훌륭한 환경이 만들어졌다.
기본적인 서블릿에 구조다. 생성이 될때는 init() 메서드가 호출이 되고 생성이 끝날때는 destory() 가 호출이 되지만 실제로 서블릿 메서드에서 우리가 필요한 service 부분이다. 위에 urlPatterns 로 들어가게 되면 req, 그리고 res 객체로 HTTP의 요청(request) 와 HTTP의 응답(response) 를 담아서 클라이언트와 주고 받는것이 기본 구조다.
서블릿 컨테이너와 서블릿 동작 방식이란?
서블릿에 이론적인 부분을 넘어서 실제로 웹 환경에서 서블릿이 동작하게 된 후에 과정을 설명 하겠다.
서블릿 컨테이너
먼저, 서블릿 컨테이너는 전 포스팅에도 설명했지만 서블릿 객체의 생명주기를 관리해준다. 가장 중요한 특징은 싱글톤 으로 관리되기 때문에 최초 요청 시점에서 서블릿 객체를 초기화 후에 서블릿 컨테이너에 보관하고, 이후에는 서블릿 컨테이너에서 같은 서블릿을 공유해서 사용하게 한다.
서블릿 요청 시 동작 과정
-
사용자가 URL 을 입력하면 HTTP Request 를 서블릿 컨테이너로 보낸다.
-
서블릿 컨테이너는 쓰레드 풀에서 쓰레드를 꺼내 할당 해주고 ServletRequest, ServeltResponse 두 객채를 생성해준다.
-
사용자가 요청한 URL 을 분석후에 어느 서블릿에 대한 요청인지 찾는다.
-
서블릿 컨테이너가 존재하지 않으면 초기화 후에 service() 메서드를 호출한다.
-
service 메서드가 끝나면 ServletResponse 객체에 응답을 보낸다.
-
응답 완료후에는 ServletRequest, Response 객체를 소멸시킨다.
웹서버를 포함한 WAS 서버의 그림도 포함되어서 설명이 되고 있다. 위에 설명했듯이 서블릿은 클라이언트의 HTTP 요청과 응답을 굉장히 쉽게 처리해주고 서블릿 컨테이너로 인해 중복적인 서블릿 생성보다 싱글톤 관리로 하나의 서블릿 객체를 여러번 사용하며 멀티쓰레드 지원 환경덕에 훨씬 좋은 환경을 개발자에게 주는것을 확인할 수 있다.
프론트 컨트롤러 패턴이란?
정말 완벽해 보이는 서블릿의 동작 방식과 서블릿 컨테이너의 요청 처리같지만 아직까지는 많은 흠이 존재한다.
해당 URL 요청이 들어올때마다 서블릿 입장에서는 새로운 서블릿 객채를 생성하고 요청을 수행할때마다 매번 스레드를 생성한다. 위에서도 보였지만 서블릿의 service 메서드는 ServletRequest, Response 등의 객체를 생성하고 이 객체를 사용하지 않는 처리 로직에서도 생성이 된다. 이는 곧 자원 낭비로 이어지고 진짜 스프링의 MVC 패턴은 공통 로직을 제거하기 위한 하나의 서블릿, 프론트 컨트롤러 혹은 Dispatcher Servlet 이라고 정의한다.
Dispatcher Servlet 이란?
정말 간단하게 나온 설명이지만 Dispatcher Servlet 은 하나의 서블릿으로 모든 요청을 처리 할 수 있게 해주는것이다.
Spring MVC의 자세한 구조는 위와 같다. 분명히 Dispatcher Servlet 을 통해서 중복적인 기능을 가진 서블릿을 생성하는것을 멈춘다는것은 이해 했지만 복잡한 구조때문에 더 이해가 안될수도 있다. 그러나 이것은 Spring MVC의 기본을 따르는 Model, View, Controller 아키텍처로 구성이 되어 있기때문이다.
MVC 관련 강의가 굉장히 길었던 만큼 2편으로 나누어서 블로그에 설명하겠다.
참고
