프론트 컨트롤러 패턴 소개
프론트 컨트롤러 도입 전
- 기존에는 각 클라이언트가 웹 애플리케이션을 호출하면 URL에 맞는 컨트롤러가 호출됬다.
- 그 안에서 공통 로직이 실행되고, 각 컨트롤러의 고유 로직이 실행되었다.
프론트 컨트롤러 도입 후
- 프론트 컨트롤러 도입 후에는 각 클라이언트가 웹 애플리케이션을 호출하면 프론트 컨트롤러가 먼저 호출된다.
- 프론트 컨트롤러에서는 공통 로직이 실행되고, 그 다음에 URL에 맞는 컨트롤러를 다시 호출한다.
프론트 컨트롤러 패턴의 특징
- 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받는다.
- 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출한다.
- 공통으로 처리할 로직을 하나로 모은다.
- 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다.
스프링 웹 MVC와 프론트 컨트롤러
- 스프링 웹 MVC의 핵심도 바로 FrontController다.
- 스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있다.
프론트 컨트롤러 도입 (v1)
- 프론트 컨트롤러를 단계적으로 도입해보자.
- 기존 코드를 최대한 유지하면서, 프론트 컨트롤러를 도입하는 것이 목표다.
- 먼저 구조를 맞추어두고 점진적으로 리펙터링 해보자.
v1 구조
컨트롤러 인터페이스 생성
- 서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다.
- 각 컨트롤러들은 이 인터페이스를 구현하면 된다.
- 프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다.
회원 등록 컨트롤러
회원 저장 컨트롤러
회원 목록 컨트롤러
프론트 컨트롤러
urlPatterns = "/front-controller/v1/*"
/front-controller/v1
를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다.- 예시
/front-controller/v1
/front-controller/v1/a
/front-controller/v1/a/b
- controllerMap
- 매핑할 URL과 각 URL이 호출될 컨트롤러에 대한 정보를 저장하는 저장소
- key
- value
- service(HttpServletRequest request, HttpServletResponse response)
- 먼저 requestURI 를 조회해서 실제 호출할 컨트롤러를 controllerMap 에서 찾는다.
- 만약 없다면 404(SC_NOT_FOUND) 상태 코드를 반환한다.
- 컨트롤러를 찾고 controller.process(request, response); 을 호출해서 해당 컨트롤러를 실행한다.
- JSP
- JSP는 이전 MVC에서 사용했던 것을 그대로 사용한다.
View 분리 (v2)
- 모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고, 깔끔하지 않다.
v2 구조
View 정의하기
- 뷰로 이동하는 부분을 깔끔하게 분리하기 위해 별도로 뷰를 처리하는 객체를 만들자.
컨트롤러 인터페이스 생성
회원 등록 컨트롤러
회원 저장 컨트롤러
회원 목록 컨트롤러
프론트 컨트롤러
- ControllerV2의 반환 타입이 MyView 이므로 프론트 컨트롤러는 컨트롤러의 호출 결과로 MyView 를 반환 받는다.
- 그리고 view.render() 를 호출하면 forward 로직을 수행해서 JSP가 실행된다.
- 프론트 컨트롤러의 도입으로 MyView 객체의 render() 를 호출하는 부분을 모두 일관되게 처리할 수 있다.
- 각각의 컨트롤러는 MyView 객체를 생성만 해서 반환하면 된다.
Model 추가 (v3)
필수로 사용하지 않는 것과 중복되는 부분 제거하기
- 서블릿 종속성 제거
- 컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 항상 필요한 것은 아니다.
- 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다.
- request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다.
- 우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자.
- 이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.
- 뷰 이름 중복 제거
- 컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다.
- 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화하자.
- 이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 고치면 된다.
- 만약
/WEB-INF/views/new-form.jsp
라면 new-form
로 단순화할 수 있다.
v3 구조
Model 정의하기
- 지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다.
- 그리고 Model도 request.setAttribute()를 통해 데이터를 저장하고 뷰에 전달했다.
- 서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.
- 이번 버전에서는 컨트롤러에서 HttpServletRequest를 사용할 수 없다.
- 따라서 직접 request.setAttribute() 를 호출할 수도 없다.
- 그래서 별도의 Model이 필요하다.
- 뷰의 이름과 뷰를 렌더링할 때 필요한 model 객체를 가지고 있다.
- model은 단순히 map으로 되어 있으므로 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.
컨트롤러 인터페이스 생성
- 이 컨트롤러는 서블릿 기술을 전혀 사용하지 않는다.
- 따라서 구현이 매우 단순해지고, 테스트 코드 작성시 테스트 하기 쉽다.
- HttpServletRequest가 제공하는 파라미터는 프론트 컨트롤러가 paramMap에 담아서 호출해주면 된다.
- 응답 결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.
회원 등록 컨트롤러
회원 저장 컨트롤러
회원 목록 컨트롤러
프론트 컨트롤러
view.render(mv.getModel(), request, response)
에서 컴파일 오류가 발생할 것이다.- FrontControllerServletV3의 내용을 참고해서 MyView에 필요한 메서드를 추가하자.
createParamMap(HttpServletRequest request)
- HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다.
- 그리고 해당 Map( paramMap )을 컨트롤러에 전달하면서 호출한다
viewResolver(String viewName)
- 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다.
- 그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.
view.render(mv.getModel(), request, response)
- 뷰 객체를 통해서 HTML 화면을 렌더링 한다.
- 뷰 객체의 render() 는 모델 정보도 함께 받는다.
- JSP는 request.getAttribute() 로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서
- request.setAttribute() 로 담아둔다.
- JSP로 포워드 해서 JSP를 렌더링 한다.
- MyView에 추가
단순하고 실용적인 컨트롤러 (v4)
- 앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다.
- 그런데 실제 컨트톨러 인터페이스를 구현할 때마다 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 번거롭다.
- 좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다.
- 이번에는 v3를 조금 변경해서 실제 구현하는 개발자들이 매우 편리하게 개발할 수 있는 v4 버전을 개발해보자.
v4 구조
- 기본적인 구조는 V3와 같다.
- 대신에 컨트롤러가 ModelView를 반환하지 않고, ViewName만 반환한다.
컨트롤러 인터페이스 생성
- 이번 버전은 인터페이스에 ModelView가 없다.
- model 객체는 파라미터로 전달되기 때문에 그냥 사용하면 되고, 결과로 뷰의 이름만 반환해주면 된다.
회원 등록 컨트롤러
회원 저장 컨트롤러
회원 목록 컨트롤러
프론트 컨트롤러
- 프론트 컨트롤러는 v3와 거의 동일하다.
- 달라진 점
- 모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다.
- 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.
- 컨트롤로가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.
유연한 컨트롤러1 (v5)
- 현재까지 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
- ControllerV3와 ControllerV4는 완전히 다른 인터페이스이다.
- 하지만 이 때
어댑터 패턴
을 사용하면 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있게 된다.
v5 구조
- 핸들러
- 클라이언트의 요청을 처리하는 처리자를 의미한다.
- 컨트롤러보다 더 큰 범위를 가지고 있다.
- 해당하는 종류의 어댑터만 있으면 컨트롤러뿐만 아니라 어떠한 것이든 다 처리할 수 있다.
- 핸들러 어댑터
- 다양한 종류의 컨트롤러를 호출할 수도록 중간 다리 역할을 해주는 연결자
- 하나의 핸들러 어댑터는 여러 개의 핸들러를 처리할 수 있다.
- 하나의 애플리케이션에는 여러 개의 핸들러 어탭터가 존재할 수 있다.
어댑터 인터페이스 생성
- boolean supports(Object handler)
- handler는 컨트롤러를 말한다.
- 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드다.
- ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
- 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
- 실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야한다.
- 이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출된다.
ControllerV3를 지원하는 어댑터
프론트 컨트롤러
- 컨트롤러(Controller) 핸들러(Handler)
- 이전에는 컨트롤러를 직접 매핑해서 사용했다.
- 그런데 이제는 어댑터를 사용하기 때문에, 컨트롤러 뿐만 아니라 어댑터가 지원하기만 하면, 어떤 것이라도 URL에 매핑해서 사용할 수 있다.
- 그래서 이름을 컨트롤러에서 더 넒은 범위의 핸들러로 변경했다.
- 생성자
- 생성자는 핸들러 매핑과 어댑터를 초기화(등록)한다.
- 매핑 정보
- 매핑 정보의 값이 ControllerV3 , ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object 로 변경되었다.
- 핸들러 매핑
- 핸들러 매핑 정보인 handlerMappingMap에서 URL에 매핑된 핸들러(컨트롤러) 객체를 찾아서 반환한다.
- 핸들러를 처리할 수 있는 어댑터 조회
- handler 를 처리할 수 있는 어댑터를 adapter.supports(handler) 를 통해서 찾는다.
- handler가 ControllerV3 인터페이스를 구현했다면, ControllerV3HandlerAdapter 객체가 반환된다.
- 어댑터 호출
- 어댑터의 handle(request, response, handler) 메서드를 통해 실제 어댑터가 호출된다.
- 어댑터는 handler(컨트롤러)를 호출하고 그 결과를 어댑터에 맞추어 반환한다.
- ControllerV3HandlerAdapter의 경우 어댑터의 모양과 컨트롤러의 모양이 유사해서 변환 로직이 단순하다.
유연한 컨트롤러2 (v5)
ControllerV4를 지원하는 어댑터
프론트 컨트롤러 수정
- FrontControllerServletV5의 initHandlerMappingMap에 코드 추가
- FrontControllerServletV5의 initHandlerAdapters에 코드 추가
정리
- 지금까지 v1 ~ v5로 점진적으로 프레임워크를 발전시켜 왔다.
- 지금까지 한 작업을 정리해보자.
- v1 (프론트 컨트롤러를 도입)
- 기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입
- v2 (View 분류)
- v3 (Model 추가)
- v4 (단순하고 실용적인 컨트롤러)
- v3와 거의 비슷
- 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
- v5 (유연한 컨트롤러)
- 어댑터 도입
- 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계
- 여기에 애노테이션을 사용해서 컨트롤러를 더 편리하게 발전시킬 수도 있다.
- 만약 애노테이션을 사용해서 컨트롤러를 편리하게 사용할 수 있게 하려면 어떻게 해야할까?
- 바로 애노테이션을 지원하는 어댑터를 추가하면 된다!
- 다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임워크의 기능을 확장할 수 있다.
- 스프링 MVC
- 지금까지 만든 것이 스프링 MVC의 핵심 구조를 파악하는데 필요한 모든 부분이다.
- 지금까지 작성한 코드는 스프링 MVC 프레임워크의 핵심 코드의 축약 버전이고, 구조도 거의 같다.
- 스프링 MVC는 지금까지 우리가 학습한 내용과 거의 같은 구조를 가지고 있다.
출처