하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰를 모두 처리하게 되면 너무 많은 역활을 부여하는 것이며 비즈니스 로직과 UI는 변경의 라이프 사이클이 다르기 때문에 유지보수에 있어 매우 불편하다
MVC(Model View Controller)
MVC패턴은 컨트롤러와 뷰 영역으로 역활을 나누어 처리하는 것을 말한다
웹애플리케이션은 보통 이 패턴을 사용한다
- 컨트롤러
HTTP요청을 받아서 파라미터를 검증하고 비즈니스 로직을 실행한다. 그리고 뷰에 전달한 데이터를 조회해서 모델에 담는다
컨트롤러에 비즈니스 로직을 둘 수 있지만 일반적으로 비즈니스 로직은 서비스 계층을 만들어 따로 처리하고 컨트롤러는 이를 호출하는 역활을 담당한다.
이렇게 되면 관심사를 분리하고 재사용성을 높이며 테스트가 용이하다 (서버 없이 service만 단위 테스트)
- 뷰
모델에 담겨있는 데이터를 사용해서 화면을 그리는 작업을 한다
FrontController
프론트컨트롤러는 서블릿이다. 하나의 서블릿으로 클라이언트의 요청을 받는 역활
클라이언트의 요청을 받으면 이에 맞는 컨트롤러를 찾아서 호출
각 컨트롤러에서 공통적으로 처리했던 작업을 프론트컨트롤러에서 처리함으로서 나머지 컨트롤러들은 서블릿을 사용하지않아도 됨
스프링웹MVC의 DispatcherServlet이 FrontController 구현체
HandlerAdapter
frontController가 url요청마다 필요한 핸들러(컨트롤러)를 찾고 호출하려면 호출로직에 대해 알고있어야하고 변경이 있을때마다 일일히 수정해야하므로 OCP위반이다
이를 위해 적합한 핸들러를 호출하는 핸들러어댑터를 추가하면 프론트컨트롤러는 어댑터를 통해 호출하므로 직접 호출하는 방식을 몰라도 되고 추가적인 핸들러는 어댑터만 추가하면 되므로 확장성도 좋으며 OCP도 준수할 수 있다
스프링MVC동작
- HTTP요청
- 핸들러 조회
- 핸들러를 처리할 수 있는 핸들러 어댑터 조회
- 핸들러 호출
- ModelAndView 반환
- viewResolver 호출
- View 반환
- View 렌더링
- 응답
ViewResolver
application/properties에 설정정보를 추가하여 적용
spring.mvc.view.prefix=/~
spring.mvc.view.suffix=.jsp
