본문 바로가기
Spring/스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] MVC 프레임워크 만들기 2

by 개발자 영만 2022. 7. 28.

유연한 컨트롤러1 - v5

만약 어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 싶다면 어떻게 해야할까?

public interface ControllerV3 {
     ModelView process(Map<String, String> paramMap);
}

public interface ControllerV4 {
     String process(Map<String, String> paramMap, Map<String, Object> model);
}

어댑터 패턴
지금까지 우리가 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
ControllerV3 , ControllerV4 는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다. 마치 v3는 110v이고, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다.
어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.

V5 구조

  • 핸들러 어댑터: 중간에 어댑터 역할을 하는 어댑터가 추가되었는데 이름이 핸들러 어댑터이다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.
  • 핸들러: 컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에 꼭 컨트롤러의 개념 뿐만 아니라 어떠한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.

MyHandlerAdapter
어댑터는 이렇게 구현해야 한다는 어댑터용 인터페이스이다.

public interface MyHandlerAdapter {

     boolean supports(Object handler);

     ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws ServletException, IOException;
}
  • boolean supports(Object handler)
    • handler는 컨트롤러를 말한다.
    • 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드다.
  • ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
    • 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
    • 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야 한다.
    • 이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출된다.

실제 어댑터를 구현해보자.
먼저 ControllerV3를 지원하는 어댑터를 구현하자.

ControllerV3HandlerAdapter

public class ControllerV3HandlerAdapter implements MyHandlerAdapter {

     @Override
     public boolean supports(Object handler) {
         return (handler instanceof ControllerV3);
     }

    @Override
     public ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) {
         ControllerV3 controller = (ControllerV3) handler;
         Map<String, String> paramMap = createParamMap(request);

         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;
     }

}

하나씩 분석해보자.

public boolean supports(Object handler) {
     return (handler instanceof ControllerV3);
}

ControllerV3 을 처리할 수 있는 어댑터를 뜻한다.

ControllerV3 controller = (ControllerV3) handler;
Map<String, String> paramMap = createParamMap(request);
ModelView mv = controller.process(paramMap);
return mv;

handler를 컨트롤러 V3로 변환한 다음에 V3 형식에 맞도록 호출한다.
supports() 를 통해 ControllerV3 만 지원하기 때문에 타입 변환은 걱정없이 실행해도 된다.
ControllerV3는 ModelView를 반환하므로 그대로 ModelView를 반환하면 된다.

FrontControllerServletV5

@WebServlet(name = "frontControllerServletV5", urlPatterns = "/frontcontroller/v5/*")
public class FrontControllerServletV5 extends HttpServlet {

     private final Map<String, Object> handlerMappingMap = new HashMap<>();
     private final List<MyHandlerAdapter> handlerAdapters = new ArrayList<>();

     public FrontControllerServletV5() {
         initHandlerMappingMap();
         initHandlerAdapters();
     }

    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());
     }

     private void initHandlerAdapters() {
         handlerAdapters.add(new ControllerV3HandlerAdapter());
     }

     @Override
     protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         Object handler = getHandler(request);
         if (handler == null) {
             response.setStatus(HttpServletResponse.SC_NOT_FOUND);
             return;
         }

        MyHandlerAdapter adapter = getHandlerAdapter(handler);
         ModelView mv = adapter.handle(request, response, handler);

         MyView view = viewResolver(mv.getViewName());
         view.render(mv.getModel(), request, response);
     }

    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");
     }

}

컨트롤러(Controller) -> 핸들러(Handler)
이전에는 컨트롤러를 직접 매핑해서 사용했다. 그런데 이제는 어댑터를 사용하기 때문에, 컨트롤러 뿐만 아니라 어댑터가 지원하기만 하면, 어떤 것이라도 URL에 매핑해서 사용할 수 있다. 그래서 이름을 컨트롤러에서 더 넒은 범위의 핸들러로 변경했다.

생성자

public FrontControllerServletV5() {
     initHandlerMappingMap(); //핸들러 매핑 초기화
     initHandlerAdapters(); //어댑터 초기화
}

생성자는 핸들러 매핑과 어댑터를 초기화(등록)한다.

매핑 정보
private final Map<String, Object> handlerMappingMap = new HashMap<>();

매핑 정보의 값이 ControllerV3 , ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object 로 변경되었다.

핸들러 매핑
Object handler = getHandler(request)

private Object getHandler(HttpServletRequest request) {
     String requestURI = request.getRequestURI();
     return handlerMappingMap.get(requestURI);
}

핸들러 매핑 정보인 handlerMappingMap 에서 URL에 매핑된 핸들러(컨트롤러) 객체를 찾아서 반환한다.

핸들러를 처리할 수 있는 어댑터 조회
MyHandlerAdapter adapter = getHandlerAdapter(handler)

for (MyHandlerAdapter adapter : handlerAdapters) {
     if (adapter.supports(handler)) {
         return adapter;
     }
}

handler 를 처리할 수 있는 어댑터를 adapter.supports(handler) 를 통해서 찾는다.
handler가 ControllerV3 인터페이스를 구현했다면, ControllerV3HandlerAdapter 객체가 반환된다.

어댑터 호출
ModelView mv = adapter.handle(request, response, handler);

어댑터의 handle(request, response, handler) 메서드를 통해 실제 어댑터가 호출된다.
어댑터는 handler(컨트롤러)를 호출하고 그 결과를 어댑터에 맞추어 반환한다.
ControllerV3HandlerAdapter 의 경우 어댑터의 모양과 컨트롤러의 모양이 유사해서 변환 로직이 단순하다.

실행

정리
지금은 V3 컨트롤러를 사용할 수 있는 어댑터와 ControllerV3 만 들어 있어서 크게 감흥이 없을 것이다. ControllerV4 를 사용할 수 있도록 기능을 추가해보자.

유연한 컨트롤러2 - v5

FrontControllerServletV5 에 ControllerV4 기능도 추가해보자.

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 추가
}

핸들러 매핑( handlerMappingMap )에 ControllerV4 를 사용하는 컨트롤러를 추가하고, 해당 컨트롤러를 처리할 수 있는 어댑터인 ControllerV4HandlerAdapter 도 추가하자.

ControllerV4HandlerAdapter

public class ControllerV4HandlerAdapter implements MyHandlerAdapter {

     @Override
     public boolean supports(Object handler) {
         return (handler instanceof ControllerV4);
    }

     @Override
     public ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) {

         ControllerV4 controller = (ControllerV4) handler;

         Map<String, String> paramMap = createParamMap(request);
         Map<String, Object> model = new HashMap<>();

         String viewName = controller.process(paramMap, model);

         ModelView mv = new ModelView(viewName);
         mv.setModel(model);

         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;
     }

}

하나씩 분석해보자.

public boolean supports(Object handler) {
     return (handler instanceof ControllerV4);
}

handler 가 ControllerV4 인 경우에만 처리하는 어댑터이다.

실행 로직

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로 만들어서 형식을 맞추어 반환한다. 마치 110v 전기 콘센트를 220v 전기 콘센트로 변경하듯이!

어댑터와 ControllerV4

public interface ControllerV4 {
     String process(Map<String, String> paramMap, Map<String, Object> model);
}

public interface MyHandlerAdapter {
     ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws ServletException, IOException;
}

실행

정리

지금까지 v1 ~ v5로 점진적으로 프레임워크를 발전시켜 왔다.
지금까지 한 작업을 정리해보자.

  • v1: 프론트 컨트롤러를 도입
    • 기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입
  • v2: View 분류
    • 단순 반복 되는 뷰 로직 분리
  • v3: Model 추가
    • 서블릿 종속성 제거
    • 뷰 이름 중복 제거
  • v4: 단순하고 실용적인 컨트롤러
    • v3와 거의 비슷
    • 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
  • v5: 유연한 컨트롤러
    • 어댑터 도입
    • 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계

여기에 애노테이션을 사용해서 컨트롤러를 더 편리하게 발전시킬 수도 있다. 만약 애노테이션을 사용해서 컨트롤러를 편리하게 사용할 수 있게 하려면 어떻게 해야할까? 바로 애노테이션을 지원하는 어댑터를 추가하면 된다!
다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임워크의 기능을 확장할 수 있다.

스프링 MVC
여기서 더 발전시키면 좋겠지만, 스프링 MVC의 핵심 구조를 파악하는데 필요한 부분은 모두 만들어보았다.
사실은 여러분이 지금까지 작성한 코드는 스프링 MVC 프레임워크의 핵심 코드의 축약 버전이고, 구조도 거의 같다.

스프링 MVC는 지금까지 우리가 학습한 내용과 거의 같은 구조를 가지고 있다.

저작자표시

'Spring > 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술' 카테고리의 다른 글

[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] 스프링 MVC - 구조 이해  (0) 2022.07.28
[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] MVC 프레임워크 만들기 1  (0) 2022.07.28
[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] 서블릿, JSP, MVC 패턴  (0) 2022.07.28
[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] 서블릿 2  (0) 2022.07.18

관련글

티스토리툴바