MVC 프레임워크 만들기
1. 프론트 컨트롤러 패턴 소개
프론트 컨트롤러 도입 전

프론트 컨트롤러 도입 후

FrontController 패턴 특징
프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받는다.
프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출해준다.
입구를 하나로!
공통 처리 가능
프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다.
스프링 웹 MVC 와 프론트 컨트롤러
스프링 웹 MVC 의 핵심도 바로 FrontController
스프링 웹 MVC 의 DispatcherServlet 이 FrontContoller 패턴으로 구현되어 있다.
2. 프론트 컨트롤러 도입 - v1
v1 구조

ControllerV1
서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다. 각 컨트롤러들은 이 인터페이스를 구현하면 된다. 프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계 없이 로직의 일관성을 가져갈 수 있다.
이제 이 인터페이스를 구현한 컨트롤러를 만들어보자. 지금 단계에서는 기존 로직을 최대한 유지하는게 핵심이다.
MemberFormControllerV1 - 회원 등록 컨트롤러
MemberSaveControllerV1 - 회원 저장 컨트롤러
MemberListControllerV1 - 회원 목록 컨트롤러
FrontControllerServletV1 - 프론트 컨트롤러
분석(프론트 컨트롤러)
urlPatterns
urlPatterns = "/front-controller/v1/*":/front-controller/v1를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다.예)
/front-controller/v1,/front-controller/v1/a,/front-controller/v1/a/b
controllerMap
key : 매핑 URL
value : 호출될 컨트롤러
service()
먼저 requestURI 를 조회해서 실제 호출할 컨트롤러를 controllerMap 에서 찾는다. 만약 없다면 404(SC_NOT_FOUND) 상태 코드를 반환한다.
컨트롤러를 찾고 controller.process(request, response); 을 호출해서 해당 컨트롤러를 실행한다.
JSP
JSP는 이전 MVC에서 사용했던 것을 그대로 사용한다.
3. View 분리 - v2
모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고, 깔끔하지 않다.
이 부분을 깔끔하게 분리하기 위해 별도로 뷰를 처리하는 객체를 만들자.
V2 구조

MyView
뷰 객체는 이후 다른 버전에서도 함께 사용하므로 패키지 위치를 frontController 에 두었다.
ControllerV2
MemberFormControllerV2 - 회원 등록 폼
이제 각 컨트롤러는 복잡한
dispatcher.forward()를 직접 생성해서 호출하지 않아도 된다. 단순히 MyView 객체를 생성하고 거기에 뷰 이름만 넣고 반환하면 된다.
ControllerV1을 구현한 클래스와ControllerV2를 구현한 클래스를 비교해보면, 이 부분의 중복이 확실하게 제거된 것을 확인할 수 있다.
MemberSaveControllerV2 - 회원 저장
MemberListControllerV2 - 회원 목록
FrontControllerServletV2
분석(View 분리)
ControllerV2의 반환 타입이 MyView 이므로 프론트 컨트롤러는 컨트롤러의 호출 결과로 MyView 를 반환 받는다.
그리고 view.render() 를 호출하면 forward 로직을 수행해서 JSP가 실행된다.
프론트 컨트롤러의 도입으로 MyView 객체의 render() 를 호출하는 부분을 모두 일관되게 처리할 수 있다. 각각의
컨트롤러는 MyView 객체를 생성만 해서 반환하면 된다.
4. 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 구조

지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model request.setAttribute() 를 통해 데이터를 저장하고 뷰에 전달했다.
서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.
(이번 버전에서는 컨트롤러에서 HttpServletRequest를 사용할 수 없다. 따라서 직접 request.setAttribute() 를 호출할 수 도 없다. 따라서 Model이 별도로 필요하다.)
ModelView
ControllerV3
이 컨트롤러는 서블릿 기술을 전혀 사용하지 않는다. 따라서 구현이 매우 단순해지고, 테스트 코드 작성시 테스트 하기 쉽다.
HttpServletRequest가 제공하는 파라미터는 프론트 컨트롤러가 paramMap에 담아서 호출해주면 된다.
응답 결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.
MemberFormControllerV3 - 회원 등록 폼
MemberSaveControllerV3 - 회원 저장
MemberListControllerV3 - 회원 목록
FrontControllerServletV3
MyView
분석(Model 추가)
createParamMap()
HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다. 그리고 해당 Map(paramMap)을 컨트롤러에 전달하면서 호출한다.
뷰 리졸버
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를 렌더링 한다.
5. 단순하고 실용적인 컨트롤러 - v4
앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트톨러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.
이번에는 v3를 조금 변경해서 실제 구현하는 개발자들이 매우 편리하게 개발할 수 있는 v4 버전을 개발해보자.
v4 구조

기본적인 구조는 v3 와 같다. 대신에 컨트롤러가 ModelView 를 반환하지 않고 ViewName 만 반환한다.
ControllerV4
이번 버전은 인터페이스에 ModelView가 없다. model 객체는 파라미터로 전달되기 때문에 그냥 사용하면 되고, 결과로 뷰의 이름만 반환해주면 된다.
MemberFormControllerV4
MemberSaveControllerV4
MemberListControllerV4
FrontControllerServletV4
분석(단순화된 컨트롤러)
FrontControllerServletV4 는 사실 이전 버전과 거의 동일하다.
모델 객체 전달
Map<String, Object> model = new HashMap<>(); //추가
모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다. 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.
뷰의 논리 이름을 직접 반환
컨트롤로가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.
정리
이번 버전의 컨트롤러는 매우 단순하고 실용적이다. 기존 구조에서 모델을 파라미터로 넘기고, 뷰의 논리 이름을 반환한다는 작은 아이디어를 적용했을 뿐인데, 컨트롤러를 구현하는 개발자 입장에서 보면 이제 군더더기 없는 코드를 작성할 수 있다.
또한 중요한 사실은 여기까지 한번에 온 것이 아니라는 점이다. 프레임워크가 점진적으로 발전하는 과정 속에서 이런 방법도 찾을 수 있었다.
프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다.
6. 유연한 컨트롤러 - v5
만약 어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 싶다면 어떻게 해야 할까?
어댑터 패턴
지금까지 우리가 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
ControllerV3 , ControllerV4 는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다. 마치 v3는 110v이고, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다.
어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.
V5 구조

핸들러 어댑터: 중간에 어댑터 역할을 하는 어댑터가 추가되었는데 이름이 핸들러 어댑터이다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.
핸들러: 컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에 꼭 컨트롤러
의 개념 뿐만 아니라 어떠한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.
MyHandlerAdapter
어댑터는 이렇게 구현해야 한다는 어댑터용 인터페이스이다.
boolean supports(Object handler)handler는 컨트롤러를 말한다.
어댑터가 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드다.
ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler)어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환해야 한다.
실제 컨트롤러가 ModelView를 반환하지 못하면, 어댑터가 ModelView를 직접 생성해서라도 반환해야 한다.
이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출 된다.
ControllerV3HandlerAdapter
FrontControllerServletV5
분석(유연한 컨트롤러)
컨트롤러(Controller) -> 핸들러(Handler)
이전에는 컨트로러를 직접 매핑해서 사용했다. 그런데 이제는 어댑터를 사용하기 때문에, 컨틀로러 뿐만 아니라 어댑터가 지원하기만 하면, 어떤 것이라도 URL 에 매핑해서 사용할 수 있다. 그래서 이름을 컨트롤러에서 더 넓은 범위의 핸들러로 변경했다.
생성자
생성자는 핸들러 매핑과 어댑터를 초기화(등록)한다.
핸들러 매핑
핸들러 매핑 정보인 handlerMappingMap 에서 URL에 매핑된 핸들러(컨트롤러) 객체를 찾아서 반환한다.
핸들러를 처리할 수 있는 어댑터 조회
handler 를 처리할 수 있는 어댑터를 adapter.supports(handler) 를 통해서 찾는다.
handler가 ControllerV3 인터페이스를 구현했다면, ControllerV3HandlerAdapter 객체가 반환된다.
어댑터 호출
어댑터의 handle(request, response, handler) 메서드를 통해 실제 어댑터가 호출된다.
어댑터는 handler(컨트롤러)를 호출하고 그 결과를 어댑터에 맞추어 반환한다. ControllerV3HandlerAdapter의 경우 어댑터의 모양과 컨트롤러의 모양이 유사해서 변환 로직이 단순하다.
정리
지금은 V3 컨트롤러를 사용할 수 있는 어댑터와 ControllerV3 만 들어 있어서 크게 감흥이 없을 것이다.
ControllerV4 를 사용할 수 있도록 기능을 추가해보자.
직접 해보자..
7. 정리
지금까지 개발한 MVC 프레임워크에 애노테이션을 사용해서 컨트롤러를 더 편리하게 발전시킬 수도 있다. 만약 애노테이션을 사용해서 컨트롤러를 편리하게 사용할 수 있게 하려면 어떻게 해야할까? 바로 애노테이션을 지원하는 어댑터를 추가하면 된다! 다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임워크의 기능을 확장할 수 있다.
스프링 MVC
여기서 더 발전시키면 좋겠지만, 스프링 MVC의 핵심 구조를 파악하는데 필요한 부분은 모두 만들어보았다. 사실은 여러분이 지금까지 작성한 코드는 스프링 MVC 프레임워크의 핵심 코드의 축약 버전이고, 구조도 거의 같다.
스프링 MVC는 지금까지 우리가 학습한 내용과 거의 같은 구조를 가지고 있다.
Last updated