강의 링크는 아래와 같습니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/
스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의
웹 애플리케이션을 개발할 때 필요한 모든 웹 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 MVC의 핵심 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., 원
www.inflearn.com
프론트 컨트롤러 도입 (V1)
저번 시간에 작성한 코드 구조는 다음과 같다. 즉, 프런트 컨트롤러를 도입하기 전 상황은 아래 이미지와 같다.
도입하고 난 후 로직은 아래 이미지와 같다.
이제 입구를 1개로 만드는 프런트 컨트롤러를 도입해보자.
프런트 컨트롤러의 특징은 아래와 같다.
- 프런트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음.
- 프런트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
- 입구를 하나로 만든다.
- 공통 처리 가능.
- 프런트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨.
스프링 웹 MVC의 핵심도 바로 FrontController이다.
스프링 웹 MVC는 DispatchServlet와 FrontController 패턴으로 구현되어 있다.
이제 프런트 컨트롤러를 단계적으로 도입해보자.
이번 V1의 목표는 기존 코드를 최대한 유지하면서, 프런트 컨트롤러를 도입하는 것이다.
먼저 구조를 맞추고 점진적으로 리팩터링 하자. V1 구조는 아래와 같다.
우선 서블릿과 유사한 모양의 컨트롤러 인터페이스를 만든다. 앞으로는 모든 프런트 컨트롤러 버전마다 인터페이스를 만들 것이다.
따라서 이후에는 생략하겠다. 프런트 컨트롤러는 이 인터페이스를 구현과 관계없이 로직의 일관성을 가질 수 있다.
public interface ControllerV1 {
void process(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException;
}
이제 인터페이스를 상속받은 회원 등록 컨트롤러, 회원 저장 컨트롤러, 회원 조회 컨트롤러 각각 V1을 만든다.
큰 그림을 위해서 세부적인 로직은 생략하겠다. 코드는 아래처럼 3개의 컨트롤러 V1을 만든다.
public class MemberFormControllerV1 implements ControllerV1 {
@Override
public void process(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
//로직실행
}
}
이제 프런트 컨트롤러를 만들어보자. 코드는 아래와 같다.
@WebServlet(name="frontControllerServletV1",urlPatterns = "/front-controller/v1/*")//v1 슬래쉬 이후에 뭐가들어와도 이 서블릿이 호출됨
public class FrontControllerServletV1 extends HttpServlet {
private Map<String,ControllerV1> controllerMap=new HashMap<>(); //컨트롤러를 담는다.
public FrontControllerServletV1() {
controllerMap.put("/front-controller/v1/members/new-form",new MemberFormControllerV1());
controllerMap.put("/front-controller/v1/members/save",new MemberSaveControllerV1());
controllerMap.put("/front-controller/v1/members",new MemberListControllerV1());
//키가 URI
}
@Override
protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
String requestURI = req.getRequestURI();
System.out.println("requestURI = " + requestURI);
ControllerV1 controller = controllerMap.get(requestURI); //다형성을 이용 URI로 해당 컨트롤러를 가져온다.
System.out.println("controllerV1 = " + controller);
if(controller==null) {
res.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
controller.process(req,res);
}
}위 코드를 바탕으로 진입점은 1개로 되었다.
프런트 컨트롤러가 생성될 때 생성자를 이용해 모든 컨트롤러를 controllerMap에 넣는다.
Http 요청이 들어오면, URI를 키로 controllerMap에서 컨트롤러를 찾고 컨트롤러를 호출해서 실행한다.
이후 컨트롤러는 JSP 파일을 렌더링 한다.
URI에 맞는 컨트롤러가 없으면 실행되지 않는다. 그러면 기존의 서블릿과 JSP로 만든 MVC와 동일하게 실행된다.
정리하면 V1은 진입점을 한 곳으로 만들었다.
View 분리 (V2)
이제 View를 분리하며 버전 2, V2로 업그레이드해보겠다.
모든 컨트롤러에서는 뷰로 이동하는 중복이 있고, 깔끔하지 않다.
String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);이 부분을 처리하기 위해 별도로 뷰를 처리하는 객체를 만들자. V2 구조는 아래와 같다.
MyView가 추가되었다. MyView 클래스 코드는 아래와 같다.
public class MyView {
private String viewPath;
public MyView(String viewPath) {
this.viewPath = viewPath;
}
public void render(HttpServletRequest request, HttpServletResponseresponse) throws ServletException, IOException {
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
}생성자를 통해 멤버 변수 viewPath 값을 받는다. render 메서드를 통해 JSP 파일을 렌더링 한다.
이제 다음 컨트롤러의 인터페이스를 만들어보자. 컨트롤러가 MyView를 리턴한다.
public interface ControllerV2 {
MyView process(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException;
}모든 컨트롤러가 new 키워드를 통해 MyView 인자로 viewPath를 만들며 MyView를 리턴한다.
이제 각 컨트롤러는 복잡한 dispatcher.forward()를 직접 생성해서 호출하지 않아도 된다.
단순히 MyView 객체를 생성하고 거기에 뷰 이름만 넣고 반환하면 된다.
ControllerV1을 구현한 클래스와 ControllerV2를 구현한 클래스를 비교해보면, 이 부분의 중복이 확실하게 제거된 것을 확인할 수 있다.
리팩터링한 FrontControllerSevletV2의 코드만 확인해보겠다.
@WebServlet(name="frontControllerServletV2",urlPatterns = "/front-controller/v2/*")
public class FrontControllerServletV2 extends HttpServlet {
private Map<String, ControllerV2> controllerMap=new HashMap<>();
public FrontControllerServletV2() {
controllerMap.put("/front-controller/v2/members/new-form",new MemberFormControllerV2());
controllerMap.put("/front-controller/v2/members/save",new MemberSaveControllerV2());
controllerMap.put("/front-controller/v2/members",new MemberListControllerV2());
//컨트롤러가 뷰를 반환하는 특징이 생김. v1과 차이
}
@Override
protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
String requestURI = req.getRequestURI();
ControllerV2 controller = controllerMap.get(requestURI); //다형성을 이용
if(controller==null) {
res.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
MyView view = controller.process(req, res);
view.render(req,res);
}
}ControllerV2의 반환 타입이 MyView 이므로 프런트 컨트롤러는 컨트롤러의 호출 결과로 MyView를 반환받는다. 그리고 view.render()를 호출하면 forward 로직을 수행해서 JSP가 실행된다.
Model 추가 (V3)
이제 Model을 추가한 V3로 넘어가 보자. 먼저 서블릿 종속성을 제거하자.
컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 꼭 필요할까?
요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다.
그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다.
우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자.
이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.
뷰 이름 중복 제거
컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다. 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프런트 컨트롤러에서 처리하도록 단순화 하자. 이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프런트 컨트롤러만 고치면 된다.
- /WEB-INF/views/new-form.jsp -> new-form
- /WEB-INF/views/save-result.jsp -> save-result
- /WEB-INF/views/members.jsp -> members
V3 구조는 아래와 같다.
ModelView
지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model도 request.setAttribute()를 통해 데이터를 저장하고 뷰에 전달했다. 서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자. 이번 버전에서는 컨트롤러에서 HttpServletRequest를 사용할 수 없다.
즉 직접 request.setAttribute()를 호출할 수 도 없다. 따라서 Model이 별도로 필요하다.
ModelView 코드는 아래와 같다.
package hello.servlet.web.frontcontroller;
import java.util.HashMap;
import java.util.Map;
public class ModelView {
private String viewName;
private Map<String, Object> model=new HashMap<>();
public ModelView(String viewName) {
this.viewName = viewName;
}
public String getViewName() {
return viewName;
}
public void setViewName(String viewName) {
this.viewName = viewName;
}
public Map<String, Object> getModel() {
return model;
}
public void setModel(Map<String, Object> model) {
this.model = model;
}
}뷰의 이름과 뷰를 렌더링 할 때 필요한 model 객체를 가지고 있다. model은 단순히 map으로 되어 있으므로 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.
컨트롤러 V3의 인터페이스 코드는 아래와 같다.
package hello.servlet.web.frontcontroller.v3;
import hello.servlet.web.frontcontroller.ModelView;
import java.util.Map;
public interface ControllerV3 {
ModelView process(Map<String, String> paramMap);
}서블릿에 의존하지 않아 구현이 단순하고, 테스트 코드 작성이 쉬워졌다.
HttpServletRequest가 제공하는 파라미터는 프런트 컨트롤러가 paramMap에 담아서 호출해주면 된다.
응답 결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.
컨트롤러 코드는 작성하지 않겠다. (궁금하면 맨 위 링크를 통해 선생님 강의를 들으면 됩니다!!!)
- MemberFormController - return new ModelAndView("new-form");으로 리턴. view의 논리적인 이름을 지정한다. 물리적인 이름은 프런트 컨트롤러에서 처리한다.
- MemberSaveController - ModelView를 객체로 만들어서 논리적인 이름을 인자로 넣고 이후 메서드인 getModel로 Map를 가져와서 put메서드를 이용해 모델인 member를 넣고 객체를 리턴한다.
- MemberListController - 마찬가지로 ModelView 객체를 만들어서 getModel로 멤버 변수 Map을 가져와서 put 메서드로 가져온 회원 데이터를 넣는다. 이후 객체를 리턴한다.
모든 컨트롤러는 매개변수로 파라미터를 넣은 paramMap을 받는다.
파라미터의 이름이 키이므로 키를 이용해 파라미터의 값을 꺼낼 수 있다.
FrontControllerServletV3의 코드는 아래와 같다.
@WebServlet(name="frontControllerServletV3",urlPatterns = "/front-controller/v3/*")
public class FrontControllerServletV3 extends HttpServlet {
private Map<String,ControllerV3> controllerMap=new HashMap<>();
public FrontControllerServletV3() {
controllerMap.put("/front-controller/v3/members/new-form",new MemberFormControllerV3());
controllerMap.put("/front-controller/v3/members/save",new MemberSaveControllerV3());
controllerMap.put("/front-controller/v3/members",new MemberListControllerV3());
}
@Override
protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
String requestURI = req.getRequestURI();
ControllerV3 controller = controllerMap.get(requestURI); //다형성을 이용
if(controller==null) {
res.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
//paramMap 모든 req의 파라미터를 가져와서 map에 넣는다
Map<String, String> paramMap=createParamMap(req);
ModelView mv = controller.process(paramMap);
String viewName=mv.getViewName();
MyView view = viewResolver(viewName);
view.render(mv.getModel(),req,res);
}
//로직이 복잡하면 로직의 수준을 맞춰줘야함
private Map<String,String> createParamMap(HttpServletRequest req) {
Map<String, String> paramMap=new HashMap<>();
req.getParameterNames().asIterator().
forEachRemaining(paramName-> paramMap.put(paramName, req.getParameter(paramName)));
return paramMap; //파라미터를 전부 뽑아서 넣어버림
}
private MyView viewResolver(String viewName){
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
}
뷰 리졸버 MyView view = viewResolver(viewName) 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다.
그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.
논리 뷰 이름: members
물리 뷰 경로: /WEB-INF/views/members.jsp
view.render(mv.getModel(), request, response)
뷰 객체를 통해서 HTML 화면을 렌더링 한다. 뷰 객체의 render()는 모델 정보도 함께 받는다.
JSP는 request.getAttribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute()로 담아둔다.
JSP로 포워드 해서 JSP를 렌더링 한다.
따라서 위에 MyView 코드에 아래 코드를 추가한다.
public void render(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
modelToRequestAttribute(model, request);
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
private void modelToRequestAttribute(Map<String, Object> model,HttpServletRequest request) {
model.forEach((key, value) -> request.setAttribute(key, value));
}쉽게 말해 우리가 만든 모델을 request 임시 저장소에 추가하며 모델을 포함해 JSP 파일을 렌더링 한다.
단순하고 실용적인 컨트롤러 (V4)
이제 ControllerV4다. V3과 다른 점은 컨트롤러가 ModelView를 반환하지 않고, ViewName만 반환한다.
이렇게 고친 이유는 실제 컨트 톨러 인터페이스를 구현하는 개발자 입장에서 보면,
항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다.
소위 실용성이 있어야 한다. 그래서 이렇게 수정했다. V4의 구조는 아래와 같다.
따라서 이전 V3 인터페이스와 다른 점은 메서드가 String을 반환한다는 것이다.
또한 모든 컨트롤러는 paramMap과 더불어 model이라는 HashMap을 매개변수로 가진다.
- MemberFormController는 정말 "new-form"이라는 뷰의 논리 이름만 반환한다.
- MemberSaveController는 인자로 받은 model(HashMap)에 member를 put 하고 뷰의 논리 이름을 반환한다.
- MemberListController도 인자로 받은 model에 mebers를 put 하고 뷰의 논리 이름을 반환한다.
리팩터링 한 FrontControllerV4의 코드는 아래와 같다.
@WebServlet(name="frontControllerServletV4",urlPatterns = "/front-controller/v4/*")
public class FrontControllerServletV4 extends HttpServlet {
private Map<String, ControllerV4> controllerMap=new HashMap<>();
public FrontControllerServletV4() {
controllerMap.put("/front-controller/v4/members/new-form",new MemberFormControllerV4());
controllerMap.put("/front-controller/v4/members/save",new MemberSaveControllerV4());
controllerMap.put("/front-controller/v4/members",new MemberListControllerV4());
}
@Override
protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
String requestURI = req.getRequestURI();
ControllerV4 controller = controllerMap.get(requestURI); //다형성을 이용
if(controller==null) {
res.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
//paramMap 모든 req의 파라미터를 가져와서 map에 넣는다
Map<String, String> paramMap=createParamMap(req);
Map<String, Object> model=new HashMap<>(); //추가
String viewName = controller.process(paramMap,model);
MyView view = viewResolver(viewName);
view.render(model,req,res);
}
//로직이 복잡하면 로직의 수준을 맞춰줘야함
private Map<String,String> createParamMap(HttpServletRequest req) {
Map<String, String> paramMap=new HashMap<>();
req.getParameterNames().asIterator().
forEachRemaining(paramName-> paramMap.put(paramName, req.getParameter(paramName)));
return paramMap; //파라미터를 전부 뽑아서 넣어버림
}
private MyView viewResolver(String viewName){
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
}V3와 비교하면 수정한 코드가 많지 않다. 정말 String 부분과 Model이라는 HashMap이 로직에 추가되었다.
이제 컨트롤러가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰 값을 찾을 수 있다.
수고스럽지만 프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편해진다!!!
유연한 컨트롤러 (V5)
이제 마지막 컨트롤러 V5다.
만약 어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 싶다면 어떻게 해야 할까? V3는 리턴 값이 ModelView이고 V4는 리턴 값이 String이다.
어댑터 패턴
지금까지 우리가 개발한 프런트 컨트롤러는 한 가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
ControllerV3 , ControllerV4는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다.
마치 v3는 110v이고, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다.
어댑터 패턴을 사용해서 프런트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.
V5의 구조는 아래 이미지와 같다.
- 핸들러 어댑터 : 중간에 어댑터 역할을 하는 어댑터가 추가되었는데 이름이 핸들러 어댑터다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.
- 핸들러 : 컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에 꼭 컨트롤러의 개념뿐만 아니라 어떠한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.
MyHandlerAdapter라는 어댑터용 인터페이스 코드를 작성했다. 아래와 같다.
public interface MyHandlerAdapter {
boolean supports(Object handler);
ModelView handle(HttpServletRequest req, HttpServletResponse res,Object handler)throws SecurityException, IOException;
}- boolean supports(Object handler)
- handler는 컨트롤러를 말한다.
- 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드다
- ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
- 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
- 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야 한다.
- 이전에는 프런트 컨트롤러가 실제 컨트롤러를 호출했지만 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출된다.
실제 어댑터를 구현해보자. 먼저 V3을 구현하는 어댑터다.
public class ControllerV3HandlerAdapter implements MyHandlerAdapter {
@Override
public boolean supports(Object handler) {
return (handler instanceof ControllerV3); //ControllerV3를 처리할 수 있는 어댑터인가
}
@Override
public ModelView handle(HttpServletRequest req, HttpServletResponse res,Object handler) throws SecurityException, IOException {
ControllerV3 controller=(ControllerV3) handler; //캐스팅
Map<String,String> paramMap=createParamMap(req);
ModelView mv = controller.process(paramMap);
return mv;
}
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName,
request.getParameter(paramName)));
return paramMap;
}
}리팩터링 한 FrontControllerServletV5는 아래와 같다.
@WebServlet(name="frontControllerServletV5",urlPatterns = "/front-controller/v5/*")
public class FrontControllerServletV5 extends HttpServlet {
private final Map<String, Object> handlerMappingMap = new HashMap<>(); //아무 컨트롤러나 다 들어가야해서 Object
private final List<MyHandlerAdapter> handlerAdapters = new ArrayList<>();//어뎁터를 넣는다.
public FrontControllerServletV5() {
initHandlerMappingMap();
initHandlerAdapters();
}
private void initHandlerAdapters() {//핸들러 어댑터를 넣는다.
handlerAdapters.add(new ControllerV3HandlerAdapter());
}
private void initHandlerMappingMap() {//핸들러를 넣는다.
handlerMappingMap.put("/front-controller/v5/v3/members/new-form", new
MemberFormControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members/save", new
MemberSaveControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members", new
MemberListControllerV3());
}
@Override
protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
Object handler=getHandler(req); //원하는 핸들러를 가져온다.
if (handler == null) {
res.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
MyHandlerAdapter adapter = getHandlerAdapter(handler);//핸들러에 맞는 어댑터를 꺼낸다.
ModelView mv = adapter.handle(req, res, handler);//어댑터가 핸들러를 실행시키고 리턴값을 받는다.
MyView view = viewResolver(mv.getViewName());
view.render(mv.getModel(), req, res);
}
private Object getHandler(HttpServletRequest request) {
String requestURI = request.getRequestURI();
return handlerMappingMap.get(requestURI);
}
private MyHandlerAdapter getHandlerAdapter(Object handler){
for(MyHandlerAdapter adapter:handlerAdapters){
if(adapter.supports(handler)){
return adapter;
}
}
throw new IllegalArgumentException("handler adapter를 찾을 수 없습니다. handler=" + handler);
}
private MyView viewResolver(String viewName) {
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
}- 생성자에서 핸들러 매핑과 어댑터를 초기화한다.
- private final Map handlerMappingMap = new HashMap <>(); 매핑 정보의 값이 ControllerV3 , ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object로 변경되었다.
- 핸들러 매핑 정보인 handlerMappingMap에서 URL에 매핑된 핸들러(컨트롤러) 객체를 찾아서 반환한다.
- handler를 처리할 수 있는 어댑터를 adapter.supports(handler)를 통해서 찾는다. handler가 ControllerV3 인터페이스를 구현했다면, ControllerV3 HandlerAdapter 객체가 반환된다.
- 어댑터의 handle(request, response, handler) 메서드를 통해 실제 어댑터가 호출된다. 어댑터는 handler(컨트롤러)를 호출하고 그 결과를 어댑터에 맞추어 반환한다. ControllerV3 HandlerAdapter의 경우 어댑터의 모양과 컨트롤러의 모양이 유사해서 변환 로직이 단순하다.
마찬가지로 V4에 관한 어댑터도 추가할 수 있다. 코드를 몇 줄 추가하면 개발자가 컨트롤러를 선택해서 개발이 가능하다.
private void initHandlerMappingMap() {
handlerMappingMap.put("/front-controller/v5/v3/members/new-form", new
MemberFormControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members/save", new
MemberSaveControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members", new
MemberListControllerV3());
//V4 추가
handlerMappingMap.put("/front-controller/v5/v4/members/new-form", new
MemberFormControllerV4());
handlerMappingMap.put("/front-controller/v5/v4/members/save", new
MemberSaveControllerV4());
handlerMappingMap.put("/front-controller/v5/v4/members", new
MemberListControllerV4());
}
private void initHandlerAdapters() {
handlerAdapters.add(new ControllerV3HandlerAdapter());
handlerAdapters.add(new ControllerV4HandlerAdapter()); //V4 추가
}
//V4도 추가ControllerV4 HandlerAdapter 코드는 아래와 같다. V3 어댑터와 정말 비슷하다.
public class ControllerV4HandlerAdapter implements MyHandlerAdapter {
@Override
public boolean supports(Object handler) {
return (handler instanceof ControllerV4);
}
//handler 가 ControllerV4 인 경우에만 처리하는 어댑터이다.
@Override
public ModelView handle(HttpServletRequest req, HttpServletResponse res, Object handler) throws SecurityException, IOException {
ControllerV4 controller=(ControllerV4) handler;
Map<String,String> paramMap=createParamMap(req);
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로 만들어서 형식을 맞추어
반환한다. 마치 110v 전기 콘센트를 220v 전기 콘센트로 변경하듯이!
*/
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName,
request.getParameter(paramName)));
return paramMap;
}
}이러면 URI 요청을 변경해도 FrontControllerServletV5가 정상적으로 동작한다.
마무리 정리를 해보자.
- v1: 프런트 컨트롤러를 도입
- 기존 구조를 최대한 유지하면서 프런트 컨트롤러를 도입
- v2: View 분류
- 단순 반복되는 뷰 로직 분리
- v3: Model 추가
- 서블릿 종속성 제거 뷰 이름 중복 제거
- v4: 단순하고 실용적인 컨트롤러
- v3와 거의 비슷 구현 입장에서
- ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
- v3와 거의 비슷 구현 입장에서
- v5: 유연한 컨트롤러
- 어댑터 도입 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계
스프링 MVC는 우리가 학습한 내용과 정말 비슷한 구조를 가지고 있다.
다음 게시글에서는 스프링 MVC에 대해 본격적으로 학습해보겠다.
이상으로 포스팅을 마칩니다. 감사합니다.
댓글