MVC란?
출처 : https://m.blog.naver.com/jhc9639/220967034588
디자인 패턴 중 하나로써, Model, View, Controller 3가지로 구성되어 있다.
MVC 등장 배경
하나의 서블릿 혹은 JSP만으로 비즈니스 로직과 뷰, 렌더링까지 모두 처리하게 되면 하나의 영역에서 너무 많은 역할을 부담지게 된다. 이는 필연적으로 유지보수가 어려워지는 결과를 낳는다.
따라서 이를 해결하기 위해 MVC가 등장했다.
Model
어플리케이션에 포함되어야할 데이터를 담는다. 이후 모델의 데이터가 view에서 출력된다.
Controller
HTTP 요청을 받아 파라미터를 검증하고 비즈니스로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해 모델에 담는다.
View
컨트롤러에서 전달된 모델에서 데이터를 가져와 화면에 보여주는 역할을 갖는다.
Spring MVC 등장 배경
기존의 MVC패턴 덕분에 각 책임이 분산되어 있지만, 여전히 각 컨트롤러 단에서는 중복 코드가 발생한다. (ex : view 생성) → 따라서 해당 중복 코드를 처리하는 프론트 컨트롤러 패턴이라는 것이 등장하였고, 이후에
DispatcherServlet이 프론트 컨트롤러의 역할을 하게 되었다.
Spring MVC의 구성요소
| Component | 설명 |
|---|---|
| DispatcherServlet | Spring MVC Framework의 Front Controller, 웹요청과 응답의 Life Cycle을 주관한다. |
| HandlerMapping | 웹요청시 해당 URL을 어떤 Controller가 처리할지 결정한다. |
| Controller | 비즈니스 로직을 수행하고 결과 데이터를 ModelAndView에 반영한다. |
| ModelAndView | Controller가 수행 결과를 반영하는 Model 데이터 객체와 이동할 페이지 정보(또는 View객체)로 이루어져 있다. |
| ViewResolver | 어떤 View를 선택할지 결정한다. |
| View | 결과 데이터인 Model 객체를 display한다. |
Spring MVC 동작순서
- Client의 요청이 들어오면 DispatchServlet이 가장 먼저 요청을 받는다.
- 핸들러 매핑을 통해 요청 url에 매핑된 핸들러(컨트롤러)를 조회한다.
- 핸들러 어댑터 목록에서 해당 요청을 처리할 수 있는 어댑터를 찾는다.
- 핸들러 어댑터를 통해 실제 핸들러(컨트롤러)를 실행한다.(handle메소드를 통해 실행함.)
- Controller는 비지니스 로직을 수행(호출)하고 결과 데이터를 ModelAndView에 반영하여 Dispatcher Servlet에 return한다.
- ViewResolver는 view name을 받아 해당하는 View 객체를 return한다.
- View는 Model 객체를 받아 rendering한다.
다양한 형태의 핸들러(컨트롤러)가 존재하기 때문입니다.
어떤 개발자는 Controller 인터페이스를 구현하는 방식의 핸들러를 구현하고 싶을 수 있고, 또 다른 개발자는 애노테이션 기반의 핸들러를 구현하고 싶을 수 있습니다.
이와 같이 개발자마다 컨트롤러(핸들러)를 구현하는 방식이 다를 수 있는데(ex : 어노테이션 기반 컨트롤러, HttpRequestHandler의 구현체, Controller 인터페이스 구현), 이 모든 요구 사항을 맞추기 위해서 어댑터가 필요한 것입니다.
ref
