Spring/MVC

[Spring MVC] 04. MVC 프레임워크 만들기

lumana 2024. 11. 20. 23:47

04. MVC 프레임워크 만들기

#Spring/MVC

정리

프론트 컨트롤러 도입 이유 - 챕터 3 마지막에 다룬 내용

포워드 중복
- View로 이동하는 코드가 항상 중복 호출되어야 한다.
- Thymeleaf 같은 다른 뷰로 변경한다면 전체 코드를 다 변경해야 한다.
사용하지 않는 코드
- 특히 HttpServletResponse의 response 객체는 현재 코드에서 사용되지 않는다.
- 이런 HttpServletRequest, HttpServletResponse를 사용하는 코드는 테스트 케이스를 작성하기도 어렵다.
공통 처리가 어렵다
- 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가한다.
- 공통 메서드로 추출해도 되지만, 호출 과정도 중복이고, 호출하는 것을 놓칠 수도 있다.

프론트 컨트롤러를 도입해보자.

원래는 각 컨트롤러마다 서블릿이 있어서 입구가 여러개였는데, 입구가 하나로 줄었다.
프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받고,
프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출해준다.
프론트 컨트롤러를 도입함으로써 공통 처리가 가능하고, 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다.

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

스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있음

프론트 컨트롤러를 도입하여 리팩토링할건데, 점진적으로 구조를 먼저 수정하고 난 다음 세부적으로 코드를 수정하자.

뭔가 개선하거나 리팩토링을 할 때는 같은 레벨끼리만 개선해야 한다. 구조적으로 개선할 꺼면 기존 코드는 최대한 그대로 유지시켜야 한다. 한 번에 다 바꿔버리면 짬봉되버린다.

ex) 구조 개선 커밋 배포 // 문제가 없으면 // 코드 개선 커밋 배포

프론트 컨트롤러 V1 - 컨트롤러 인터페이스 도입

서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입하자.
인터페이스를 도입함으로써 프론트 컨트롤러는 구현과 관계없이 로직 일관성을 유지할 수 있다. (느슨한 결합)

public interface ControllerV1 {
    void process(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException;
}

코드는 수정하지 않는다 했으므로 구현체에는 기존 로직을 그대로 넣어주자.
MemberFormControllerV1

public class MemberFormControllerV1 implements ControllerV1 {
    @Override
    public void process(HttpServletRequest request, HttpServletResponse
        response) throws ServletException, IOException {
        String viewPath = "/WEB-INF/views/new-form.jsp";
        RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
        dispatcher.forward(request, response);
    }
}

@WebServlet가 사라졌고, HttpServlet을 상속받지 않아도 된다.

이런식으로 Save, List 컨트롤러도 만들자.
(생략)

이제 FrontController를 구현해보자.


@WebServlet(name = "frontControllerServletV1", urlPatterns = "/front-controller/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());
    }

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse
        response)
        throws ServletException, IOException {
        System.out.println("FrontControllerServletV1.service");
        String requestURI = request.getRequestURI();
        ControllerV1 controller = controllerMap.get(requestURI);
        if (controller == null) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
        controller.process(request, response);
    }
}

FrontController 입구 하나만 존재해야 하기 때문에,
- urlPatterns = "/front-controller/v1/*": /front-controller/v1를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다.
controllerMap에다가는 매핑 정보를 저장해뒀다가, 요청 정보(URL)를 보고 알맞은 컨트롤러를 꺼내준다.
service()
- 먼저 requestURI를 조회해서 실제 호출할 컨트롤러를 controllerMap에서 찾는다.
- 만약 없다면 404(SC_NOT_FOUND) 상태 코드를 반환한다.
- 컨트롤러를 찾고 controller.process(request, response);을 호출해서 해당 컨트롤러를 실행한다.

V2 : View 분리

이제 코드 레벨에서 수정해보자. 이번 버전에서는 뷰로 이동하는 부분의 중복을 제거하고, 로직을 분리해보자.
이를 위해 별도로 뷰를 처리하는 객체를 만들자.

MyView

public class MyView {
    private String viewPath;

    public MyView(String viewPath) {
        this.viewPath = viewPath;
    }

    public void render(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
        RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
        dispatcher.forward(request, response);
    }
}

view에 대한 관심사를 MyView 클래스에서 처리해준다. 일단은 view로 이동하는 로직을 이 클래스에서 처리하자. (객체 지향을 잘 이해하고 있는 분이라면 MyView 클래스에서 할 수 있는 역할이 더 많다는 것이 보일 것이다. 아래에서 계속해서 MyView에다가 뷰과 관련된 로직을 추가해줄 것이다.)

ControllerV2 인터페이스는 기존 ControllerV1과 역할이 동일하다.

MemberFormControllerV2 - 회원 등록 폼

public class MemberFormControllerV2 implements ControllerV2 {
    @Override
    public MyView process(HttpServletRequest request, HttpServletResponse
        response) throws ServletException, IOException {
        return new MyView("/WEB-INF/views/new-form.jsp");
    }
}

이제 각 Controller는 dispatcher.forward()를 직접 생성해서 호출하지 않아도 된다.
단순히 MyView 객체를 생성하고 거기에 뷰 이름만 넣고 반환하면 된다.

MemberSaveControllerV2 - 회원 저장

public class MemberSaveControllerV2 implements ControllerV2 {
    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public MyView process(HttpServletRequest request, HttpServletResponse
        response) throws ServletException, IOException {
        // 중략
        memberRepository.save(member);
        request.setAttribute("member", member);
        return new MyView("/WEB-INF/views/save-result.jsp");
    }
}

MemberListControllerV2 - 회원 목록

public class MemberListControllerV2 implements ControllerV2 {
    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public MyView process(HttpServletRequest request, HttpServletResponse
        response) throws ServletException, IOException {
        List<Member> members = memberRepository.findAll();
        request.setAttribute("members", members);
        return new MyView("/WEB-INF/views/members.jsp");
    }
}

이런식으로 컨트롤러에서는 이제 model(request 객체)에 값을 넣어주고 MyView만 리턴해주면 된다.

프론트 컨트롤러 V2
MyView 객체에 있는 render()를 누군가는 호출해줘야 한다. 이를 프론트 컨트롤러가 처리해준다.

@WebServlet(name = "frontControllerServletV2", urlPatterns = "/front-controller/v2/*")
public class FrontControllerServletV2 extends HttpServlet {
    // 중략
	// 기존과 동일
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse
        response)
        throws ServletException, IOException {
        String requestURI = request.getRequestURI();
        ControllerV2 controller = controllerMap.get(requestURI);
        if (controller == null) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
		// 변경된 부분
        MyView view = controller.process(request, response);
        view.render(request, response);
    }
}

V3 - Model 추가, 서블릿 의존성 최소화, View 이름 중복 제거

강의 맨 처음에서 설명했듯이, 이제 프론트 컨트롤러 입구 1개만 존재하는데, 각 컨트롤러에 굳이 HttpServletRequest, HttpServletResponse가 필요하지 않는다.
어차피 Response는 사용하지 않았고, 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다.

또한 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다.
이렇게 하면 구현하는 컨트롤러가 서블릿 기술에 의존할 필요가 없어진다.

또한, 컨트롤러에서 지정하는 뷰 이름에 중복이 있다. 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자. 이렇게 함으로써 뷰의 폴더가 이동해도 프론트 컨트롤러 한 곳만 고쳐주면 된다. 이 역할은 viewResolver가 처리한다.

또한, MyView의 render를 호출할 때 request, response가 아니라 model을 전달한다.

ModelView

public class ModelView {
    private String viewName;
    private Map<String, Object> model = new HashMap<>();

    public ModelView(String viewName) {
        this.viewName = viewName;
    }
	// Getter, Setter
	// 생략
}

뷰의 이름과 뷰를 렌더링할 때 필요한 model 객체를 가지고 있다. model은 단순히 map으로 되어 있으므로 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.

ControllerV3

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

서블릿 기술을 전혀 사용하지 않는다.
응답 결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.

MemberFormControllerV3 - 회원 등록 폼

public class MemberFormControllerV3 implements ControllerV3 {
    @Override
    public ModelView process(Map<String, String> paramMap) {
        return new ModelView("new-form");
    }
}

이제는 서블릿 관련 로직이 다 빠졌다. 단순히 Model과 View 논리 이름만 신경써주면 된다.

MemberSaveControllerV3 - 회원 저장

public class MemberSaveControllerV3 implements ControllerV3 {
    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public ModelView process(Map<String, String> paramMap) {
        // 생략
        memberRepository.save(member);
        ModelView mv = new ModelView("save-result");
        mv.getModel().put("member", member);
        return mv;
    }
}

파라미터 정보는 paramMap에 담겨있다. paramMap에서 필요한 요청 파라미터를 조회하면 된다.
ModelView에서 Model을 꺼내 값을 넣어준다.
ModelView에 논리 이름을 넣어준다.

MemberListControllerV3 - 회원 목록
얘도 SaveController 처럼 구현하면 된다. 생략

FrontControllerServletV3

@WebServlet(name = "frontControllerServletV3", urlPatterns = "/front-controller/v3/*")
public class FrontControllerServletV3 extends HttpServlet {
    // 기존과 동일
	// 생략

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse
        response)
        throws ServletException, IOException {
        String requestURI = request.getRequestURI();
        ControllerV3 controller = controllerMap.get(requestURI);
        if (controller == null) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
        Map<String, String> paramMap = createParamMap(request);
        ModelView mv = controller.process(paramMap);
        String viewName = mv.getViewName();
        MyView view = viewResolver(viewName);
        view.render(mv.getModel(), request, response);
    }

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

    private MyView viewResolver(String viewName) {
        return new MyView("/WEB-INF/views/" + viewName + ".jsp");
    }
}

createParamMap() : 컨트롤러에 httpRequest파라미터 정보를 전달하기 위한 객체 생성 HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다. 그리고 해당 Map( paramMap )을 컨트롤러에 전달하면서 호출한다.

viewResolver
컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환 한다.

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

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

어? JSP는 Map이 아니라 request.getAttribute()로 조회하지 않나요?
MyView에서 render할 때 Model 값을 request에 넣어줘야 한다.

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

V4 -

항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.

개인적인 생각으론 ModelView를 만든 이유는 Model과 View 두 개를 반환할 수 없어서 일 것이다
파라미터로 Model을 참조변수를 넘기면 되지 않을까?
컨트롤러 호출 시 Model을 참조변수로 넘겨서 여기다가 데이터를 저장해두자.

그러면 이제 컨트롤러에서는 단순히 View의 논리이름만 반환해주면 된다.
ControllerV4

public interface ControllerV4 {
    /**
     * @param paramMap
     * @param model
     * @return viewName
     */
    String process(Map<String, String> paramMap, Map<String, Object> model);
}

Tip: 인텔리제이에서 /** 하고 엔터를 치면 자바독스 같은 주석이 나타난다.

MemberFormControllerV4

public class MemberFormControllerV4 implements ControllerV4 {
    @Override
    public String process(Map<String, String> paramMap, Map<String, Object>
        model) {
        return "new-form";
    }
}

컨트롤러는 이제 논리이름만 반환해주면 된다.

SaveController도 단순해진다.

@Override
    public String process(Map<String, String> paramMap, Map<String, Object> 
        model) {
       // 중략
        memberRepository.save(member);
        model.put("member", member);
        return "save-result";
    }

model.put("member", member) 모델이 파라미터로 전달되기 때문에, 모델을 직접 생성하지 않아도 된다.

회원 목록 컨트롤러는 생략한다.

FrontControllerServletV4

@WebServlet(name = "frontControllerServletV4", urlPatterns = "/front-controller/v4/*")
public class FrontControllerServletV4 extends HttpServlet {
    // 기존과 동일
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse
        response)
        throws ServletException, IOException {
        String requestURI = request.getRequestURI();
        ControllerV4 controller = controllerMap.get(requestURI);
        if (controller == null) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
        Map<String, String> paramMap = createParamMap(request);
        Map<String, Object> model = new HashMap<>(); // 추가
        String viewName = controller.process(paramMap, model);
        MyView view = viewResolver(viewName);
        view.render(model, request, response);
    }
// 기존과 동일
// 생략

Map<String, Object> model = new HashMap<>();
Model을 프론트 컨트롤러에서 만들어서 각 컨트롤러에 전달해주는 로직만 추가되었다.

뷰의 논리 이름을 직접 반환


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

컨트롤로가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.

여기까지 단순하고 실용적이도록 프레임워크가 만들어지는 과정을 봤다.
중요한 사실은 여기까지 한번에 온 것이 아니라는 점이다.
프레임워크가 점진적으로 발전하는 과정 속에서 이런 방법도 찾을 수 있었다.

프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다.

V5 : 유연한 컨트롤러 1: 어댑터 패턴

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

어댑터 패턴

지금까지 우리가 개발한 프론트 컨트롤러는 한 가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
ControllerV3, ControllerV4는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다.

어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.

클라이언트에서 요청이 오면 핸들러 매핑 정보에서 핸들러를 조회한다
- controllerMap.put("/front-controller/v4/members/new-form", new MemberFormControllerV4()); 이런 정보가 저장되어 있는 controllerMap
핸들러(=컨트롤러) 어댑터를 찾아온다. V3를 처리할 수 있는 어댑터, V4를 처리할 수 있는 어댑터…
기존에는 프론트 컨트롤러에서 핸들러를 바로 호출했지만, 이제는 어댑터를 통해서 호출해야 한다. 마치 콘센트 어댑터를 거치는 것 처럼이다.
- 어댑터한테 컨트롤러를 넘겨준다.
어댑터가 알아서 다른 걸 호출해준다.
어댑터가 Model&View를 Front Controller에게 반환해준다.
… (생략)

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

핸들러 어댑터를 구현해보자.

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

위에서 설명했듯이 핸들러 어댑터는 핸들러(컨트롤러)를 호출하고(handle) Model&View를 반환받아야 한다.
handle 메서드

boolean supports(Object handler)는 뭔가요?

어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드다.
어댑터도 인터페이스다. 110V용, 220V용 어댑터가 있듯이, 핸들러 어댑터도 V3용, V4용… 이 존재한다.
지원 여부를 V3어댑터, V4어댑터와 같은 구현체에서 확인할 것이다.

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

컨트롤러를 호출하고 MV를 받는 로직이
프론트 컨트롤러에서 핸들러 어댑터로 넘어왔음을 확인할 수 있다.

ControllerV3 controller = (ControllerV3) handler;

supports()를 통해 ControllerV3만 지원하기 때문에 타입 변환은 걱정없이 실행해도 된다.

FrontControllerServletV5
컨트롤러를 호출하는 로직은 빠졌다. 하지만 올바른 핸들러어댑터를 골라주는 로직이 추가되어야 한다.

@WebServlet(name = "frontControllerServletV5", urlPatterns = "/front-controller/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); // 1. 핸들러 매핑 정보로 핸들러를 가져온다. (Object 참조 MemberFormControllerV3가 나온다.)

        if (handler == null) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }

        MyHandlerAdapter adapter = getHandlerAdapter(handler); // 2. 찾은 핸들러에 알맞은 어댑터를 찾아서 가져온다. (V3HandlerAdapter)
        ModelView mv = adapter.handle(request, response,
                handler); // 3, 어댑터에게 핸들러를 넘겨준다. (V3HandlerAdapter 에게 Object 참조 V3 컨트롤러를 넘겨준다)
        // 4. 알맞은 핸들러가 실행된다. (V3 컨트롤러가 캐스팅되서 process()가 실행된다)
        // 5. ModelView 를 반환한다.

        String viewName = mv.getViewName();
        MyView view = viewResolver(viewName); // 6. viewResolver 를 호출한다.
        // 7. view 를 받아온다.

        view.render(mv.getModel(), request, response); // 8. render(model)을 호출한다.
    }

    private MyHandlerAdapter getHandlerAdapter(Object handler) {
        for (MyHandlerAdapter adapter : handlerAdapters) {
            if (adapter.supports(handler)) {
                return adapter;
            }
        }
        throw new IllegalArgumentException("handler adapter를 찾을 수 없습니다. handler=" + handler);
    }

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

    private MyView viewResolver(String viewName) {
        return new MyView("/WEB-INF/views/" + viewName + ".jsp");
    }

}

initHandlerAdapters() : 핸들러 어댑터를 등록해놓는다.

매핑 정보

private final Map<String, Object> handlerMappingMap = new HashMap<>();

매핑 정보의 값이 ControllerV3, ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object로 변환되었다. 만약 Object가 아니라면 추상화하여 처리할 수 없다.

핸들러 매핑

private Object getHandler(HttpServletRequest request)

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

핸들러를 처리할 수 있는 어댑터 조회

private MyHandlerAdapter getHandlerAdapter(Object handler)

어댑터 호출 로직 추가

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

V4용 어댑터도 추가해보자

initHandlerMappingMap()와 initHandlerAdapters()에 매핑 정보를 추가하자.
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;
    }
}

V3 V4로 넘어오면서 바뀌었던

Map<String, Object> model = new HashMap<>();
String viewName = controller.process(paramMap, model);

이 부분이 어댑터에서도 똑같이 바뀌었고,

view 호출 로직이 V3에 맞춰져있다 보니

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

view 논리이름을 받아 ModelView를 변환해주는 로직이 추가되었다. 마치 어댑터가 전압을 변환해주는 역할과 같다.

코드를 확장했는데 수정하는 부분이 별로 없다. 프론트 컨트롤러에서는 매핑정보와 핸들러어댑터 초기화를 빼고는 손대지 않았다.

단순히 V4핸들러어댑터만 추가한 것이다. OCP를 위반하지 않는다.
완전히 OCP를 지키려면 초기화 부분만 빼서 외부에서 주입해주면 된다.

우리가 만든 프레임워크는 역할과 구현이 잘 분리되어 있다. 인터페이스를 통해 핸들러 어댑터가 구현되어 있고, 인터페이스를 통해서 핸들러를 호출한다.

설계를 더 많이 한다면

핸들러 매핑 정보도 인터페이스화 할 수 있고,
어댑터 목록도 인터페이스화 할 수 있고,
viewResolver도 인터페이스화 할 수 있다.

완전히 인터페이스 기반으로 모아두고, 바꾸고 싶은 부분만 중간에 구현체를 넣어주면 된다. (외부에서 설정해서 주입하도록)
그래서 컨트롤러를 애노테이션으로 처리한다 해도 이 v5 코드는 절대 바뀌지 않는다.

지금까지 배운 내용이 Spring MVC에서 그대로 적용한 내용이다. Spring MVC도 과거에는 인터페이스 기반이었다가 애노테이션이 유행하면서 @Controller를 처리할 수 있는 핸들러 어댑터를 끼어넣은 것이다.

Ref) 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 강의 | 김영한 - 인프런

'Spring > MVC' 카테고리의 다른 글

[Spring MVC] 06. 스프링 MVC - 기본 기능 (0)	2024.11.24
[Spring MVC] 05. 스프링 MVC - 구조 이해 (0)	2024.11.21
[Spring MVC] 03. 서블릿, JSP, MVC 패턴 (0)	2024.11.19
[Spring MVC] 02. 서블릿 (0)	2024.11.19
[Spring MVC] 01. Web Application의 이해 (0)	2024.11.19

현재글[Spring MVC] 04. MVC 프레임워크 만들기

Brute force Study

배움을 나누는 공간 https://github.com/DawnGlow

Today :
Yesterday :

일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Brute force Study

[Spring MVC] 04. MVC 프레임워크 만들기

04. MVC 프레임워크 만들기

정리

프론트 컨트롤러 V1 - 컨트롤러 인터페이스 도입

V2 : View 분리

V3 - Model 추가, 서블릿 의존성 최소화, View 이름 중복 제거

V4 -

V5 : 유연한 컨트롤러 1: 어댑터 패턴

어댑터 패턴

V4용 어댑터도 추가해보자

'Spring > MVC' 카테고리의 다른 글

'Spring/MVC'의 다른글

티스토리툴바

[Spring MVC] 04. MVC 프레임워크 만들기

04. MVC 프레임워크 만들기

정리

프론트 컨트롤러 V1 - 컨트롤러 인터페이스 도입

V2 : View 분리

V3 - Model 추가, 서블릿 의존성 최소화, View 이름 중복 제거

V4 -

V5 : 유연한 컨트롤러 1: 어댑터 패턴

어댑터 패턴

V4용 어댑터도 추가해보자

'Spring > MVC' 카테고리의 다른 글

'Spring/MVC'의 다른글

관련글

티스토리툴바