MVC 프레임워크가 나오기까지의 과정 (2)

이전 글에서, 프론트 컨트롤러 패턴을 도입하면 공통 처리에 대한 부분들을 해결할 수 있다고 했었다.
이게 무슨 말일까? 그림으로 확인하면 이해하기 쉽다. 아래의 2개의 그림을 보자.

첫번째 그림은 프론트 컨트롤러 패턴을 적용하기전의 그림, 즉 저번 글에서 단순하게 MVC 패턴만 적용했던 경우이고,
두번째 그림은 MVC 패턴을 적용한 상태에서 프론트 컨트롤러 패턴까지 적용한 경우이다.

프론트 컨트롤러 패턴의 특징은 다음과 같다.

• 프론트 컨트롤러만 서블릿으로 만들어 HTTP 요청을 받고, 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
• 프론트 컨트롤러에서 다른 컨트롤러 모두가 해야하는 공통처리를 수행
• 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않음

스프링 웹 MVC의 핵심도 바로 프론트 컨트롤러이다.
스프링 웹 MVC의 DispatcherServlet이 프론트 컨트롤러 패턴으로 구현되어있다.

프론트 컨트롤러 만으로 모든 것이 다 해결되나?

당연히 프론트 컨트롤러만 도입한다고 MVC 프레임워크가 완성되는 것은 아니다.
스프링 웹 MVC의 프론트 컨트롤러인 DispatcheServlet가 핵심적인 역할을 하는 것도 맞지만, 스프링 웹 MVC는 DispatcheServlet만으로 동작하지 않는다. 최종적인 MVC 프레임워크가 완성되기 위해서 추가되어야하는 기능들은 아래와 같이 훨씬 많다.

• 핸들러 매핑
• 핸들러 어댑터
• 뷰 리졸버
• 아규먼트 리졸버
• 등등등...

직접 MVC 프레임워크를 자바 코드로 작성하여 만드는 과정은 생략한다.
대신, MVC 프레임워크가 동작하는 순서를 포괄적으로 복기해보자.

1. 프론트 컨트롤러(스프링 MVC에서는 DispatcherServlet)로 HTTP 요청이 도착
2. 프론트 컨트롤러는 HTTP 요청의 경로를 이용하여 해당 요청을 처리해줄 핸들러를 핸들러 매핑에서 조회
3. 핸들러 매핑에 의해 핸들러가 결정되면, 프론트 컨트롤러는 결정된 핸들러를 처리할 수 있는 핸들러 어댑터를 조회
4. 결정된 핸들러 어댑터에 의해서 핸들러 로직이 수행되고 로직의 결과가 반환
5. 반환된 결과 값이 핸들러 어댑터 -> 프론트 컨트롤러로 전달
6. 프론트 컨트롤러는 반환된 결과값을 토대로 뷰 리졸버를 통해 알맞은 뷰를 반환
7. 프론트 컨트롤러는 반환된 뷰를 통해 화면을 렌더링

물론, 자세한 동작과정은 더 복잡하다.
포괄적인 순서이므로 이렇게 알고, 다음 글인 스프링 MVC에서 좀 더 자세히 알아보자.