4. MVC 프레임워크 만들기

1. FrontController

 

프론트 컨트롤러 도입 후

FrontController 패턴 특징

- 프론트 컨트롤러, 서블릿 하나로 클라이언트의 요청을 받음

- 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출

- 공통 기능 처리

- 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨

 

스프링 웹 MVC와 프론트 컨트롤러

스프링 웹 MVC의 핵심도 바로 FrontController이다.

스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되었다.

 

 

 

 

2. 프론트 컨트롤러 도입 - V1

 

V1 구조

 

V1 FrontController

 

 

 

 

 

3. View 분리 - V2

 

V2 구조

 

V2 MyView

 

V2 FrontController

 

 

 

 

 

 

4. Model 추가 - V3

 

서블릿 종속성 제거

컨트롤러 입장에서 HttpServletRequest, HttpServletResponse가 꼭 필요할까?

요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 서블릿 기술을 몰라도 동작할 수 있다. (?)

그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다.

V3에서는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자.

 

 

뷰 이름 중복 제거

컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다.

컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화하자.

이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도, 프론트 컨트롤러만 고치면 된다.

 

 

V3 구조

 

 

V3 ModelView

 

V3 MyView

 

V3 FrontController

 

ModelView

지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다.

그리고 Model도 request.setAttribute()를 통해 데이터를 저장하고 뷰에 전달했다.

 

서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.

 

- 뷰의 이름과 뷰를 렌더링할 때 필요한 model 객체를 가지고 있다.

- model은 단순히 map으로 되어 있으므로, 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.

 

 

FrontController

creatParamMap()

- HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다.

   그리고 해당 Map(paramMap)을 컨트롤러에 전달하면서 호출한다.

 

 

뷰 리졸버

MyView view = viewResolver(viewName)

- 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다.

 

 

뷰 렌더링

view.render(modelView.getModel(), request, response)

- 뷰 객체를 통해서 HTML 화면을 렌더링한다.

- 뷰 객체의 render()는 모델 정보도 함께 받는다.

- JSP는 request.getAttribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute()로 담아둔다.

- JSP로 포워드해서 JSP를 렌더링한다.

 

 

 

 

5. Model 객체를, 단순하게 Map으로 - V4

 

v3는 아키텍처 측면에서 잘 설계되었지만, ModelView 객체를 생성하고 반환하는 부분이 번거롭다.

이를 조금 더 Map<Object, String> 으로 조금 더 단순하게 바꿔보자.

 

 

 

 

 

 

 

 

 

6. 어댑터 컨트롤러 구조 - V5

 

 

 

 

위 플로우대로 코드를 따라가보면 다음과 같다.

 

 

1. 핸들러 조회

- 기존에 정의해둔 handlerMappingMap 에 현재 들어온 request URL과 매핑된 Handler(즉, Controller) 객체가 있는지 조회한다.

- 만약 URL과 매핑된 Controller가 없다면, 404 Error를 띄운다.

 

 

 

2. 어댑터 조회

- Controller를 처리할 수 있는 어댑터가 있는지, 기존에 정의한 handlerAdapters에서 조회한다.

 

 

 

3. 어댑터의 handle() 호출

4. handle()의 handler()(컨트롤러 로직, process()) 호출

5. ModelvView 반환

- 1번에서 Object로 매핑한 컨트롤러를 어댑터 형식에 맞는 컨트롤러로 바꾸고, 기존 컨트롤러의 로직을 실행한다.

(여기에서는 ModelView 반환 형식으로 통일)

 

 

 

6. viewResolver() 호출

7. MyView 반환

8. render(model) 호출

- viewResolver에서 논리주소를 물리주소로 변환한다.

- 이후의 과정은 이전과 같다.