Spring MVC가 등장하기 전 Servlet의 역할은 상당히 많았습니다.
예를들어...
위와 같이 Servlet의 doGet 메소드 안에서 여러가지 로직이 혼재되어있습니다. MVC에 익숙한 사람들이라면 비즈니스 로직과 뷰 로직이 함께 있는 것을 보고 의아해 알 것이라고 예상합니다. MVC가 Model, View, Controller로 독립된 모듈로 나누어서 개발을 용이하게 만드는 패턴이기 때문입니다. 덧붙여 View로직을 위에 코드와 같이 직접 html tag를 붙이면서 개발을 하는 것은 말도 안된다고 생각합니다.
따라서 Dispatcher Servlet과 함께 Sprinv MVC가 등장하면서 개발환경이 많이 발전했습니다. 그렇다면 Dispatcher Servlet은 무엇일까요?
Dispatcher Servlet은 servlet이자 front controller입니다. Dispatcher Servlet도 Servlet이기 때문에 일단 Request가 들어오면 Response처리를 해주어야 합니다. 하지만 Request 처리 방식은 Servlet과 조금 다릅니다. 과거에는 "하나의 URL 요청 = 하나의 Servlet"으로 만들어주어야 했었다면 Spring MVC는 DispatcherServlet를 Front Controller로서 맨 앞에 하나를 설정해놓습니다. 이 Dispatcher Servlet이 모든 URL 요청을 우선 받고 HandlerMapping을 통해 다양한 URL 요청을 처리할 수 있는 Controller(사실 Dispatcher Servlet만으로 다양한 요청처리는 아직 힘들고 Reflection과 Annotation에 힘을 빌려야 합니다, 다음에 포스팅 예정입니다)에게 요청 처리 작업을 위임합니다. Controller는 그 후에 View, Model에게 뷰로직과 비즈니스 로직을 위임합니다. Servler에서 모든 것을 처리하는 모습과는 완전히 바뀌었습니다. 다음은 Controller를 사용했을 때 로직이 어떻게 분리되는지 보여줍니다.
부연 설명을 조금 드리자면 Service 클래에게 business logic를 위임하고 ResponseEntity같은 것에 담거나 return를 해주면 View로직이 실행되는 구조입니다.
Spring MVC는 Dispatcher Servlet를 적극적으로 이용해서 Servlet이 맡고 있던 책임을 분산시켜 더욱 객체지향적으로 프로그래밍을 할 수 있게 도와줍니다. 객체지향적으로 프로램을 한다는 의미는 객체가 자신의 역할을 맡고 협력을 한다는 의미입니다. 따라서 MVC가 각자 다른 역할을 맡고 협력을 하는 점에서 더욱 객체지향적이라고 생각합니다.
설명감사합니다!