[Spring] MVC 내부구조

기존 Servlet MVC의 몇 가지 문제점들

Spring에서 제공하는 MVC 패턴은 편리한 기능을 많이 제공합니다. Servlet에서 겪을 수 있던 공통적인 부분들을 포함해서 몇 가지 문제점들을 해결해서 지금의 Spring이 되었습니다.

기존의 Servlet MVC 구조에서 찾아볼 수 있는 문제점들은 아래와 같습니다.

1. Controller들에서 공통적인 작업들을 수행해야할 경우에 깔끔한 해결 방법이 없다. (결국 method를 공통적으로 실행하는 방법 정도밖에 없다.)
2. 뷰 로직이 반복된다.
3. 서블릿에 크게 종속되어있다.
4. 뷰를 직접 찾아야 한다.
5. 구현하는 service함수에서는 고정된 인자를 받아야 한다.

이 문제들을 해결하기 위해 Spring은 아래와 같은 구조를 프레임워크에 도입합니다.

Spring MVC 구조

1. 사용자의 모든 Request를 Dispatcher Servlet에서 받습니다.
   • 이 Dispatch Servlet은 부모로 HttpServlet을 구현하고 있고, root path service를 통해 모든 request를 받습니다.
2. Request URL에 맞춰 어떤 Controller를 실행해야할지 선택합니다.
   • Controller들은 annotation을 통해 구분할 수 있습니다. 특히 내부 메서들에 mapping annotation을 따로 붙여주므로 여기에 맞춰 mapper가 실행할 controller를 탐색합니다.
3. 선택한 Controller의 형상(signature)에 맞게 실행해줄 HandlerAdapter를 찾습니다.
4. HandlerAdapter는 Controller를 실행합니다.
   • 이 HandlerAdapter의 역할은 각기 다른 Controller 함수 모양에 맞춰 실행해주는 역할입니다.
5. Controller가 실행되고 View의 이름을 다시 HandlerAdapter에게 return해줍니다.
6. 전달받은 view의 이름으로 ViewResolver를 통해 View를 생성합니다.
7. View를 render합니다.
8. render된 view와 함께 사용자에게 응답이 전달됩니다.

Servlet의 문제들이 어떻게 해결되었는지?

전반적인 구조는 위와 같습니다. 이때 어떤 부분이 위에서 언급했던 문제들을 해결했을까요?

1. 공통적인 작업들을 수행하기위해 Dispatcher Servlet을 도입하였습니다.
2. 1번덕에 반복되는 뷰 로직을 공통처리할 수 있습니다.
3. Controller에서는 Servlet이 사용되는줄 모르고 모든 요청과 응답을 처리합니다.
4. View 식별자만 주면 ViewResolver가 view를 대신 생성해줍니다.
5. HandlerAdapter를 통해 다양한 인자의 Controller들을 유연하게 실행할 수 있습니다. 필요한 경우에는 여러 인자들을 주입해줍니다.