[SPRING] FrontController 패턴 (v1~v5)

14 분 소요

개요

FrontController 도입 전

스크린샷 2022-06-17 오후 12 29 30

FrontController 도입 후

스크린샷 2022-06-17 오후 12 29 40

FrontController 패턴 특징

프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음
프론터 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
입구를 하나로!
공통 처리 가능
프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨

스프링 웹 MVC와 FrontController

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

💎 v1 - 프론트 컨트롤러 도입

컨트롤러 인터페이스 -> 컨트롤러 구현체 -> 프론트 컨트롤러 순으로 개발한다.

v1 구조

스크린샷 2022-06-17 오후 1 52 29

클라이언트의 http 요청이 들어오면. FrontController는 URL 매핑 정보에서 컨트롤러를 조회한 뒤에 해당 컨트롤러를 호출한다.
컨트롤러가 직접 JSP forward를 진행한다.
JSP가 html 응답을 전송한다.

v1 구현

1. 컨트롤러 인터페이스

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

서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다. 각 컨트롤러들은 이 인터페에스를 구현하면 된다.
프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다.
이 인터페이스를 구현한 컨트롤러를 만든 뒤에, 프론트 컨트롤러를 만든다.

2. 컨트롤러 구현체

MemberSaveControllerV1.java

public class MemberSaveControllerV1 implements ControllerV1 {

    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public void process(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        String username = req.getParameter("username");
        int age = Integer.parseInt(req.getParameter("age"));

        Member member = new Member(username, age);
        memberRepository.save(member);

        // Model에 데이터를 보관한다.
        req.setAttribute("member", member);

        // 컨트롤러 -> 뷰 호출
        String viewPath = "/WEB-INF/views/save-result.jsp";
        RequestDispatcher dispatcher = req.getRequestDispatcher(viewPath);
        dispatcher.forward(req, res);
    }
}

MemberSaveController는 회원을 저장하는 기능이다. 이 이에도 MemberFormController와 MemberListController가 존재한다.

3. 프론트 컨트롤러

@WebServlet(name = "frontControllerServletV1", urlPatterns = "/front-controller/v1/*") // /front-controller/v1 을 포함한 모든 하위 요청은 이 서블릿에서 받아들인다.
public class FrontControllerServletV1 extends HttpServlet {

    // 매핑 정보 저장 // (key, value): (매핑 URL, 호출될 컨트롤러)
    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());
    }

    // service(): requestURL를 받은 뒤, 실제 호출할 컨트롤러를 controllerMap에서 찾아 호출한다.
    @Override
    protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        System.out.println("FrontControllerServletV1.service");

        String requestURI = req.getRequestURI();
        ControllerV1 controller = controllerMap.get(requestURI); // 부모는 자식을 받을 수 있다. (다형성)

        if (controller == null) {
            res.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }

        controller.process(req, res); // 해당 컨트롤러를 실행한다.
    }
}

프론트 컨트롤러는 URI에 따른 컨트롤러 매핑 정보를 저장한다.
service()에서 해당하는 컨트롤러를 호출한다.

💎 v2 - View 분리

v1에는 모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고 깔끔하지 않다.

 String viewPath = "/WEB-INF/views/members.jsp";
        RequestDispatcher dispatcher = req.getRequestDispatcher(viewPath);
        dispatcher.forward(req, res);

이 부분을 깔끔하게 분리하기 위해 별도로 뷰를 처리하는 객체를 만들자.

v2 구조

스크린샷 2022-06-17 오후 1 51 32

클라이언트의 http 요청이 들어오면 FrontController가 매핑정보를 찾아서 해당하는 컨트롤러를 호출한다.
컨트롤러가 직접 JSP forward를 하지 않고, 뷰 역할을 하는 MyView 라는 객체를 반환한다.
FrontController가 MyView에 있는 render()를 호출한다.
MyView가 JSP foward를 진행한다.
JSP가 html 응답을 전송한다.

v2 구현

1. MyView

public class MyView {

    private String viewPath;

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

    public void render(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        RequestDispatcher dispatcher = req.getRequestDispatcher(viewPath);
        dispatcher.forward(req, res);
    }
}

컨트롤러에서 뷰로 이동하는 코드를 MyView에 따로 뺀다.

2. 컨트롤러 인터페이스

public interface ControllerV2 {

    MyView process(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException; // 🌟 리턴타입이 MyView이다.
}

컨트롤러 인터페이스는 v1과 유사하지만 리턴타입이 void가 아닌 MyView이다.

3. 컨트롤러 구현체

MemberSaveControllerV2.java

public class MemberSaveControllerV2 implements ControllerV2 {

    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public MyView process(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        String username = req.getParameter("username");
        int age = Integer.parseInt(req.getParameter("age"));

        Member member = new Member(username, age);
        memberRepository.save(member);
        req.setAttribute("member", member); // Model에 데이터를 보관한다.

        return new MyView("/WEB-INF/views/save-result.jsp"); // 🌟 MyView 객체에 viewPath를 담아서 반환한다.
    }
}

4. 프론트 컨트롤러

@WebServlet(name = "frontControllerServletV2", urlPatterns = "/front-controller/v2/*") // /front-controller/v2 을 포함한 모든 하위 요청은 이 서블릿에서 받아들인다.
public class FrontControllerServletV2 extends HttpServlet {

    // 매핑 정보 저장 // (key, value): (매핑 URL, 호출될 컨트롤러)
    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());
    }

    // service(): requestURL를 받은 뒤, 실제 호출할 컨트롤러를 controllerMap에서 찾아 호출한다.
    @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);// 🌟 MyView 객체를 반환한다.
        view.render(req, res); // 🌟 MyView에 있는 render()를 호출하면 foward 로직을 수행해서 JSP가 실행된다.

    }
}

프론트 컨트롤러의 도입으로 MyView 객체의 render()를 호출하는 부분을 모두 일관되게 처리할 수 있다.
각각의 컨트롤러는 MyView 객체를 생성만 해서 반환하면 된다.

💎 v3 - Model 추가 🌟

서블릿 종속성 제거

컨트롤러 입장에서 HttpServletRequest와 HttpServletResponse가 꼭 필요할까?
요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다. 그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 마들어서 반환하면 된다.
우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자. 이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다는 장점이 있다.

뷰 이름 중복 제거

컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 잇다.
컨트롤러는 ‘뷰의 논리 이름’을 반환하고. 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자.
💡 이렇게 해두면 향후 뷰의 폴더 위치가 이동하더라도, 컨트롤러 구현체를 일일이 변경할 필요 없이, 프론트 컨트롤러만 변경하면 된다.

/SEB-INF/views/new-form.jsp -> new-form
/SEB-INF/views/save-result.jsp -> save-result
/SEB-INF/views/members.jsp -> members

v3 구조

스크린샷 2022-06-17 오후 3 17 07

클라이언트의 http 요청이 들어오면 FrontController가 매핑정보를 찾아서 해당하는 컨트롤러를 호출한다.
컨트롤러는 모델과 뷰가 같이 섞여 있는 ModelView라는 객체를 반환한다.
FrontController가 viewResolver를 호출하면, viewResolver에서 논리 이름을 물리 위치로 변환해서 MyView 객체를 반환한다.
FrontController가 MyView 안에 있는 render(model)를 호출한다.

v3 구현

1. ModelView

지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model도 req.setAttribute()를 통해 데이터를 저장하고 뷰에 전달했다.
서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.
(이전 버전에서는 컨트롤러에서 HttpServletRequest를 사용할 수 없다, 따라서 직접 req.setAttribute()를 호출할 수도 없다. 따라서 Model이 별도로 필요하다.)

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

2. 컨트롤러 인터페이스

public interface ControllerV3 {

    ModelView process(Map<String, String> paramMap); // 서블릿에 종속적이지 않다.
}

컨트롤러에서 HttpServletRequest와 HttpServletResponse를 사용하지 않음으로써 서블릿 종속성을 제거했다.
process()는 ModelView 객체를 반환한다.

3. 컨트롤러 구현체

MemberSaveControllerV3.java

public class MemberSaveControllerV3 implements ControllerV3 {

    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public ModelView process(Map<String, String> paramMap) {

        // 🌟  paramMap에서 파라미터 정보를 꺼내 쓴다.
        String username = paramMap.get("username");
        int age = Integer.parseInt(paramMap.get("age"));

        Member member = new Member(username, age);
        memberRepository.save(member);

        ModelView mv = new ModelView("save-result"); // 🌟 뷰의 전체 path가 아닌 논리적인 이름을 넣는다.
        mv.getModel().put("member", member);

        return mv;
    }
}

4. 프론트 컨트롤러

@WebServlet(name = "frontControllerServletV3", urlPatterns = "/front-controller/v3/*") // /front-controller/v3 을 포함한 모든 하위 요청은 이 서블릿에서 받아들인다.
public class FrontControllerServletV3 extends HttpServlet {

    // 매핑 정보 저장 // (key, value): (매핑 URL, 호출될 컨트롤러)
    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());
    }

    // service(): requestURL를 받은 뒤, 실제 호출할 컨트롤러를 controllerMap에서 찾아 호출한다.
    @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;
        }

        Map<String, String> paramMap = createParamMap(req);
        ModelView mv = controller.process(paramMap);// 🌟 paramMap을 넘겨준다.

        String viewName = mv.getViewName(); // 논리이름 (ex. new-form)
        MyView view = viewResolver(viewName); // 🌟 논리이름으로 물리위치를 반환한다.

        view.render(mv.getModel(), req, res); // 🌟 render()를 호출하면서 Model 정보를 넘긴다.
    }

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

    // 🌟 HttpServletRequest에서 파라미터 정보를 모두 꺼내서 Map으로 반환한다.
    private Map<String, String> createParamMap(HttpServletRequest req) {

        Map<String, String> paramMap = new HashMap<>();

        // 파라미터 이름과 value를 꺼내서 paramMap에 집어넣는다.(put)
        req.getParameterNames().asIterator()
                .forEachRemaining(paramName -> paramMap.put(paramName, req.getParameter(paramName)));

        return paramMap;
    }
}

프론트 컨트롤러의 코드가 복잡해진 것처럼 보이지만, 컨트롤러 구현체들의 코드가 간결해졌으며 유지보수 하기에도 좋아졌다.

5. MyView

public class MyView {

    private String viewPath;

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

    public void render(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        RequestDispatcher dispatcher = req.getRequestDispatcher(viewPath);
        dispatcher.forward(req, res);
    }

    public void render(Map<String, Object> model, HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        modelToRequestAttribute(model, req); // 🌟 Model에 있는 데이터를 RequestAttribute로 바꾼다.
        RequestDispatcher dispatcher = req.getRequestDispatcher(viewPath);
        dispatcher.forward(req, res);
    }

    private void modelToRequestAttribute(Map<String, Object> model, HttpServletRequest req) {
        // 🌟 JSP는 req.getAttribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 req.setAttrubute()로 담아둔다.
        model.forEach((key, value) -> req.setAttribute(key, value)); 
    }
}

💎 v4 - 단순하고 실용적인 컨트롤러

앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다.
그런데 실제 컨트롤러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.
이번에는 v3를 조금 변경해서 실제 구현하는 개발자들이 매우 편리하게 개발할 수 있는 v4 버전을 개발해보자.

v4 구조

스크린샷 2022-06-17 오후 5 13 16

클라이언트의 http 요청이 들어오면 FrontController가 매핑정보를 찾아서 해당하는 컨트롤러를 호출한다. (이때, model을 같이 넘겨준다. 🌟)
컨트롤러가 ModelView 대신에 ViewName을 반환한다. 🌟
FrontController가 viewResolver를 호출하면, viewResolver에서 논리 이름을 물리 위치로 변환해서 MyView 객체를 반환한다.
FrontController가 MyView 안에 있는 render(model)를 호출한다.

전체적인 구조는 v3와 유사하다.

v4 구현

1. 컨트롤러 인터페이스

public interface ControllerV4 {

    /**
     * @param paramMap
     * @param model
     * @return viewName
     */
    String process(Map<String, String> paramMap, Map<String, Object> model); // 🌟 model 객체도 받아온다.
}

이번 버전은 인터페이스에 ModelView가 없다. model 객체는 파라미터로 전달되기 때문에 그냥 사용하면 되고, 결과로 뷰의 이름만 반환해주면 된다.

2. 컨트롤러 구현체

public class MemberSaveControllerV4 implements ControllerV4 {

    private MemberRepository memberRepository = MemberRepository.getInstance();

    @Override
    public String process(Map<String, String> paramMap, Map<String, Object> model) {

        String username = paramMap.get("username");
        int age = Integer.parseInt(paramMap.get("age"));

        Member member = new Member(username, age);
        memberRepository.save(member);

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

        return "save-result";  // 🌟 ModelView 객체가 아닌, 단순하게 뷰의 논리이름을 직접 반환한다.
    }
}

3. 프론트 컨트롤러

@WebServlet(name = "frontControllerServletV4", urlPatterns = "/front-controller/v4/*") // /front-controller/v4 을 포함한 모든 하위 요청은 이 서블릿에서 받아들인다.
public class FrontControllerServletV4 extends HttpServlet {

    // 매핑 정보 저장 // (key, value): (매핑 URL, 호출될 컨트롤러)
    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());
    }

    // service(): requestURL를 받은 뒤, 실제 호출할 컨트롤러를 controllerMap에서 찾아 호출한다.
    @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;
        }

        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); // render()를 호출하면서 Model 정보를 넘긴다.
    }

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

    // HttpServletRequest에서 파라미터 정보를 모두 꺼내서 Map으로 반환한다.
    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;
    }
}

프론트 컨트롤러는 v3와 거의 동일하다.
달라진 점은, 모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다는 것이다. 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다. 🌟

정리

이번 버전의 컨트롤러는 매우 단순하고 실용적이다. 기존 구조(=v3)에서 모델을 파라미터로 넘기고, viewModel 대신 뷰의 논리 이름을 반환한다는 작은 아이디어를 적용했을 뿐인데, 컨트롤러를 구현하는 개발자 입장에서 보면 이제 군더더기 없는 코드를 작성할 수 있다.
또한 중요한 사실은 여기까지 한번에 온 것이 아니라는 점이다. 프레임워크가 점진적으로 발전하는 과정 속에서 이런 방법도 찾을 수 있다.

💎 v5 - 유연한 컨트롤러 1

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

public interface ControllerV3 {
    String 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 구조

스크린샷 2022-06-17 오후 6 14 59

클라이언트의 http 요청이 들어오면 핸들러 매핑 정보에서 핸들러를 조회한다. 🌟
핸들러 어댑터 목록에서 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다. 🌟
(ControllerV3를 처리할 수 있는 어댑터, ControllerV4를 처리할 수 있는 어댑터, …)
프론트 컨트롤러에서 핸들러 어댑터를 통해서만 핸들러(컨트롤러)를 호출할 수 있다. 🌟
핸들러 어댑터가 핸들러(컨트롤러)를 호출한 뒤에 ModelView를 반환한다. 🌟
v4에서와 마찬가지로 viewResolver를 호출하면, viewResolver에서 논리 이름을 물리 위치로 변환해서 MyView 객체를 반환한다.
FrontController가 MyView 안에 있는 render(model)를 호출한다.

핸들러 어댑터

중간에 어댑터 역할을 하는 어댑터가 추가되었는데, 이름이 핸들러 어댑터이다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.

핸들러

컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에, 꼭 컨트롤러의 개념 뿐만 아니라 어떤한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.

v5 구현 (ControllerV3)

1. MyHandlerAdapter

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

public interface MyHandlerAdapter {

    // 해당 핸들러(컨트롤러)를 지원할 수 있으면 True
    boolean supports(Object handler);

    // 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
    ModelView handle(HttpServletRequest req, HttpServletResponse res, Object handler) throws ServletException, IOException;
}

handle()에서 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야 한다.
이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만, 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출된다.

2. 헨들러 어댑터

ControllerV3를 지원하는 어댑터이다.

public class ControllerV3HandlerAdapter implements MyHandlerAdapter {

    @Override
    public boolean supports(Object handler) {

        // handelr 객체가 ControllerV3의 구현체라면 True 반환
        return (handler instanceof ControllerV3);
    }

    @Override
    public ModelView handle(HttpServletRequest req, HttpServletResponse res, Object handler) throws ServletException, IOException {

        ControllerV3 controller = (ControllerV3) handler; // supports()를 통해 ControllerV3만 지원하기 때문에 타입변환을 실행해도 된다.

        Map<String, String> paramMap = createParamMap(req);
        ModelView mv = controller.process(paramMap); // 핸들러 어댑터가 실제 핸들러(컨트롤러)를 호출해 modelView를 받아온다.

        return mv;
    }

    // HttpServletRequest에서 파라미터 정보를 모두 꺼내서 Map으로 반환한다.
    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;
    }
}

3. 프론트 컨트롤러

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

    private final Map<String, Object> handlerMappingMap = new HashMap<>(); // 🌟 매핑 정보의 값이 ControllerV3, ControllerV4 같은 인터페이스가 아니라, 아무 값이나 받을 수 있는 Object로 변경되었다.
    private final List<MyHandlerAdapter> handlerAdapters = new ArrayList<>();

    public FrontControllerServletV5() {

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

    // ControllerV3 핸들러 매핑 정보 저장
    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 req, HttpServletResponse res) throws ServletException, IOException {

        // 1. 핸들러 조회 🌟
        Object handler = getHandler(req); // MemberFormControllerV3 반환
        if (handler == null) {
            res.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }

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

        // 3. handle() 메서드를 통해 어댑터를 호출하고, 어댑터는 핸들러(컨트롤러) 호출 후 어댑터에 맞는 modelView를 반환한다. 🌟
        ModelView mv = adapter.handle(req, res, handler);

        // 4. viewResolver 호출
        String viewName = mv.getViewName(); // 논리이름 (ex. new-form)
        MyView view = viewResolver(viewName); // 논리이름으로 물리위치를 반환한다.

        // 5. render(model) 호출
        view.render(mv.getModel(), req, res); // render()를 호출하면서 Model 정보를 넘긴다.
    }

    // 해당 handler를 처리할 수 있는 어댑터를 adapter.supports()를 통해 찾는다.
    private MyHandlerAdapter getHandlerAdapter(Object handler) {

        // 1. handler가 ControllerV3 인터페이스를 구현했다면,
        for (MyHandlerAdapter adapter : handlerAdapters) {
            if (adapter.supports(handler)){
                return adapter; // 2. ControllerV3HandlerAdapter 객체가 반환된다.
            }
        }
        throw new IllegalArgumentException("handler adapter를 찾을 수 없습니다. handler = " + handler);
    }

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

        String requestURI = req.getRequestURI();
        return handlerMappingMap.get(requestURI); 
    }

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

💎 v5 - 유연한 컨트롤러 2

기존 v5 코드에 추가한다.

v5 구현 (ControllerV4)

1. 핸들러 어댑터

ControllerV4를 지원하는 어댑터이다.

public class ControllerV4HandlerAdapter implements MyHandlerAdapter {

    @Override
    public boolean supports(Object handler) {

        // handelr 객체가 ControllerV4의 구현체라면 True 반환
        return (handler instanceof ControllerV4);
    }

    @Override
    public ModelView handle(HttpServletRequest req, HttpServletResponse res, Object handler) throws ServletException, IOException {

        ControllerV4 controller = (ControllerV4) handler;

        Map<String, String> paramMap = createParamMap(req);
        HashMap<String, Object> model = new HashMap<>(); // 모델 추가

        String viewName = controller.process(paramMap, model); // 컨트롤러의 process() 메서드에서 모델에 필요한 데이터를 담아놓는다.

        /*
        * ControllerV4는 ModelView가 아니라 viewName을 반환한다.
        * 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야 한다. 🌟
        */
        ModelView mv = new ModelView(viewName); // 뷰 setting
        mv.setModel(model); // 모델 setting

        return mv;
    }

    // HttpServletRequest에서 파라미터 정보를 모두 꺼내서 Map으로 반환한다.
    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;
    }
}

handle()에서 어댑터가 꼭 필요한 이유가 나온다.
ControllerV4는 뷰의 이름을 반환했지만, 어댑터는 이것을 ModelView로 만들어서 형식을 맞추어 반환한다.
마치 110v 전기 콘센트를 220v 전기 콘센트로 변경하듯이!

2. 프론트 컨트롤러

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

...

  // ControllerV3와  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());

        // 🌟 추가
        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()); // 🌟 추가
    }

...

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

정리

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

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

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

스프링 MVC

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

💛 개인 공부 기록용 블로그입니다. 👻

맨 위로 이동하기

Twitter Facebook LinkedIn

Minju412

개요

FrontController 도입 전

FrontController 도입 후

FrontController 패턴 특징

스프링 웹 MVC와 FrontController

💎 v1 - 프론트 컨트롤러 도입

v1 구조

v1 구현

1. 컨트롤러 인터페이스

2. 컨트롤러 구현체

3. 프론트 컨트롤러

💎 v2 - View 분리

v2 구조

v2 구현

1. MyView

2. 컨트롤러 인터페이스

3. 컨트롤러 구현체

4. 프론트 컨트롤러

💎 v3 - Model 추가 🌟

서블릿 종속성 제거

뷰 이름 중복 제거

v3 구조

v3 구현

1. ModelView

2. 컨트롤러 인터페이스

3. 컨트롤러 구현체

4. 프론트 컨트롤러

5. MyView

💎 v4 - 단순하고 실용적인 컨트롤러

v4 구조

v4 구현

1. 컨트롤러 인터페이스

2. 컨트롤러 구현체

3. 프론트 컨트롤러

정리

💎 v5 - 유연한 컨트롤러 1

어댑터 패턴

v5 구조

핸들러 어댑터

핸들러

v5 구현 (ControllerV3)

1. MyHandlerAdapter

2. 헨들러 어댑터

3. 프론트 컨트롤러

💎 v5 - 유연한 컨트롤러 2

v5 구현 (ControllerV4)

1. 핸들러 어댑터

2. 프론트 컨트롤러

정리

스프링 MVC

공유하기

참고

누군가 나의 EC2를 해킹하여 사용하는 경우

[Trouble Shooting] AWS EC2 멈춤 현상 (CPU Utilization)

EC2, Docker Compose를 이용한 애플리케이션 배포 (with. Docker Hub)

[BOJ] 10448 - 유레카 이론 (🥉 브론즈 1티어)