FrontController 패턴 특징
- 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음
- 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
- 입구를 하나로!
- 공동 처리 가능
- 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨
스프링 웹 MVC와 프론트 컨트롤러
- 스프링 웹 MVC의 핵심도 바로 FrontController
- 스프링 웹 MVC의 DispatcherServlet이 FrontContoller 패턴으로 구현되어 있음
프론트 컨트롤러 도입 -v1
서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다. 각 컨트롤러들은 이 인터페이서를 구현하면 된다. 프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다.
프론트 컨트롤러 분석
urlPatterns
urlPatterns = "/front-controller/v1/*":/front-controller/v1를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다.- 예)
/front-controller/v1,/front-controller/v1/a,/front-controller/v1/a/b
controllerMap
- key : 매핑 URL
- value : 호출될 컨트롤러
service()
먼저 requestURI를 조회해서 실제 호출할 컨트롤러를 controllerMap에서 찾는다. 만약 없다면 404(SC_NOT_FOUND) 상태 코드를 반환한다.
컨트롤러를 찾고 controller,process(request, response);을 호출해서 해당 컨트롤러를 실행한다.
JSP
JSP는 이전 MVC에서 사용했던 것을 그대로 사용한다.
Model 추가 -v3
- 컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 꼭 필요할까?
요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다.
그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다.
우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하고 않도록 변경해보자
이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.
뷰 이름 중복 제거
컨트롤러에서 지정하느 뷰 이름에 중복이 있는 것을 확인할 수 있다. -> new MyView("/WEB-INF/views/members.jsp");
컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자.
이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 고치면 된다.
논리 주소를 물리주소 변환한다.
/WEB-INF/views/new-form.jsp-> new-form/WEB-INF/views/save-result.jsp-> save-result/WEB-INF/views/members.jsp-> members
- 매핑 정보를 가져와서 컨트롤러 호출해서
- 기존에는 뷰를 반환했지만 모델과 뷰가 섞여있는 모델뷰를 반환
- 논리 주소를 물리 주소로 바꾸는 역할을 하는 viewResolver
ModelView
지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model도 request.setAttribute() 를 통해 데이터를 저장하고 뷰에 전달했다.
서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.
(이번 버전에서는 컨트롤러에 HttpServletRequest를 사용할 수 없다. 따라서 직접 request.setAttribute()를 호출할 수도 없다. 따라서 Model이 별도로 필요하다.)
참고로 ModelView 객체는 다른 버전에서도 사용하므로 패키를 frontcontroller에 둔다.
뷰의 이름과 뷰를 렌더링할 때 필요한 model 객체를 가지고 있다. model은 단순히 map으로 되어 있으므로 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.
controllerV3
이 컨트롤러는 서블릿 기술을 전혀 사용하지 않는다. 따라서 구련이 매우 단순해지고, 테스트 코드 작성시 테스트 하기 쉽다.
HttpServletRequest가 제공하는 파라미터는 프론트 컨트롤러가 paramMap에 담아서 호출해주면 된다.
응답 결과로 뷰 이름과 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.
MemberFormControllerV3
ModelView를 생성할 때 new-form이라는 view의 논리적인 이름을 지정한다. 실제 물리적인 이름은 프론트 컨트롤러에서 처리한다.
MemberSaveControllerV3
paramMap.get("username)
파라미터 정보는 map에 담겨있다. map에 필요한 요청 파라미터를 조회하면 된다.
mv.getModel().put("member", member)
모델은 단순한 map이므로 모델에 뷰에서 필요한 member 객체를 담고 반환한다.
FrontControllerServlet
view.render(mv.getModel(), request, resposne) 코드에서 컴파일 오류가 발생할 것이다. 다음 코드를 참고해서 Myview 객체에 필요한 메서드를 추가하자.
createParaMap()
HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다. 그리고 해당 Map(paramMap)을 컨트롤러에 전달하면서 호출한다.
뷰 리졸버
MyView view = viewReslover(viewName)
컨트롤러가 반환한 논리 뷰 이름을 실ㄹ제 물리 뷰 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.
- 논리 뷰 이름 :
members - 물리 뷰 경로 :
/WEB-INF/views/members.jsp
view.render(mv.getModel(), request, response)
- 뷰 객체를 통해서 HTML 화면을 렌더링 한다.
- 뷰 객체의
render()는 모델 정보도 함께 받는다. - JSP는
request.getAtrribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서request.setAttribute()로 담아둔다. - JSP로 포워드 해서 JSP를 렌더링 한다.
단순하고 실용적인 컨트롤러 - v4
앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트롤러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다,
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.
- 기본적인 구조는 v3와 같다. 대신에 컨트롤러가
ModelView를 반환하지 않고,viewName만 반환한다.
모델 객체 전달
Map<String, Object> model = new HashMap<>();
모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다. 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.
뷰의 논리 이름을 직접 반환
String viewName = controller.process(paramMap, model);
MyView view = viewResolver(viewName);컨트롤러가 직접 뷰의 논리 이름을 반호나하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.
유연한 컨트롤러1 -v5
만약 어떤 개발자는 controllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 시다면 어떻게 해야할까?
어댑터 패턴
지금까지 우리가 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다. controllerV3, ControllerV4는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다. 마치 v3는 110v이고 v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 어댑터이다.
어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.
- 핸들러 어댑터 : 중간에 어댑터 역할을 하는 어댑터가 추가 되었는데 이름이 핸들러 어댑터이다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.
- 핸들러 : 컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에 꼭 컨트롤러의 개념 뿐만 아니라 어떠한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.
MyHandlerAdapter
boolean supports(Object handler)- handler는 컨트롤러를 말한다.
- 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드이다.
ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler)- 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
- 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 Modelview를 직접 생성해서라도 반환해야 한다.
- 이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만 이제는 이 어댑터를 통해서 실제 큰트롤러가 호출된다.
ControllerV3HandlerAdapter
public boolean supports(Object handler) {
return (handler instanceof ControllerV3);
}ControllerV3를 처리할 수 있는 어댑터를 뜻한다.
ControllerV3 controller = (ControllerV3) handler;
Map<String, String> paramMap = createParaMap(request);
ModelView mv = controller.process(paramMap);handler를 컨트롤러 V3로 반환한 다음에 V3 형식에 맞도록 호출한다.
supports()를 통해 ControllerV3만 지원하기 때문에 타입 변환은 걱정없이 실행해도 된다.
ControllerV3는 ModelView를 반환하므로 그대로 ModelView를 반환하면 된다.
FrontControllerServletV5
컨트롤러(Controller) -> 핸들러(Handler)
이전에는 컨트롤러를 직접 매핑해서 사용했다. 그런데 이제는 어댑터를 사용하기 떄문에, 컨트롤러 뿐만 아니라 어댑터가 지원하기만 하면, 어떤 것이라도 URL에 매핑해서 사용할 수 있다. 그래서 이름을 컨트롤러에서 더 넓은 범위인 핸들러로 변경했다.
생성자
private void initHandlerAdaptors() {
handlerAdaptors.add(new ControllerV3HandlerAdaptor());
handlerAdaptors.add(new ControllerV4HandlerAdaptor());
}생성자는 핸들러 매핑과 어댑터를 초기화(등록)한다.
매핑 정보
private final Map<String, Object> handlerMappingMap = new HashMap<>();
매핑 정보의 값이 ControllerV3 ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object로 변경되었다.
핸들러 매핑
Object handelr = getHandler(request)
private Object getHandler(HttpServletRequest request) {
String requestURI = request.getRequestURI();
return handlerMappingMap.get(requestURI);
}핸들러 매핑 정보인 handlerMappingMap에서 URL에 매핑된 핸들러(컨트롤러) 객체를 찾아서 반환한다.
핸들러를 처리할 수 있는 어댑터 조회
MyHandlerAdaptor adaptor = getHandlerAdapter(handler)
for (MyHandlerAdaptor adaptor : handlerAdaptors) {
if (adaptor.supports(handler)) {
return adaptor;
}
}handler를 처리할 수 있는 어댑터를 adapter.supports(handler)를 통해서 찾는다.
handler가 ControllerV3 인터페이스를 구현했다면, ControllerV3HandlerAdapter가 반환된다.
어댑터 호출
ModelView mv = adapter.handle(request, response, handler)
어댑터의 handle(request, response, hnadler) 메서드를 통해 실제 어댑터가 호출된다.
ControllerV3HandAdaptor의 경우 어댑터의 모양과 컨트롤러의 모양이 유사해서 변환 로직이 단순하다.
유연한 컨트롤러2 -v5
ControllerV4HandlerAdapter
실행 로직
ControllerV4 controller = (ControllerV4) handler;
Map<String, String> paramMap = createParamMap(request);
Map<String, Object> model = new HashMap<>();
String viewName = controller.process(paramMap, model)handler를 ControllerV4로 캐스팅 하고, paramMap, model을 만들어서 해당 컨트롤러를 호출한다. 그리고 viewName을 반환 받는다.
어댑터 변환
ModelView mv = new Modelview(viewName);
mv.setModel(model);
return mv;어댑터에서 이 부분이 단순하지만 중요한 부분이다.
어댑터가 호출하는 ControllerV4는 뷰의 이름을 반환한다. 그런데 어댑터는 뷰의 이름이 아니라 ModelView를 만들어서 반환해야 한다. 여기서 어댑터가 꼭 필요한 이유가 나온다.
ControllerV4는 뷰의 이름을 반환했지만, 어댑터는 이것으 ModelView로 만들어서 형식을 맞추어 반환한다.
