[스프링 MVC 1편] Chapter4. MVC 프레임워크 만들기
V1. 프론트 컨트롤러 도입
FrontController 패턴: 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음. 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출. 입구를 하나로 -> 공통 처리 가능. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨
서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다. 각 컨트롤러들(MemberFormControllerV1...)은 이 인터페이스를 구현하면 된다. 프론트 컨 트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다.
프론트 컨트롤러에서 다형성을 활용하여 Map<String,ControllerV1> controllerMap에 컨트롤러들을 넣는다. (여기서 String은 매핑 URL) 그후에 requestURI을 조회해서 실제 호출할 컨트롤러를 controllerMap에서 찾는다.
V2. View 분리
모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있기 때문에, 분리를 하여 별도로 뷰를 처리하는 객체를 만든다.
// 중복코드
String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
컨트롤러가 뷰를 반환함으로써 컨트롤러를 dispatcher.forward()를 직접 생성하여 호출하지 않아도 된다. 컨트롤러V2에서MyView 객체를 생성하고 뷰이름을 넣고 반환하면 중복이 제거된다.
프론트 컨트롤러의 도입으로 MyView 객체의 render() 를 호출하는 부분을 모두 일관되게 처리할 수 있다. 각각의 컨트롤러는 MyView 객체를 생성만 해서 반환하면 된다. 메소드를 호출함으로써 forward 로직을 실행서 JSP가 실행된다.
V3. Model 추가
V2에서는 ControllerV2 메소드에 HttpServletRequest와 HttpServletResponse를 인자로 받고 있다. 요청 파라미터 정보를 자바 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작 할 수 있다. 그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.
컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자. 이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 고치면 된다.
지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model도 request.setAttribute() 를 통해 데이터를 저장하고 뷰에 전달했다. 서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체(ModelView)를 만든다.
HttpServletRequest가 제공하는 파라미터는 프론트 컨트롤러가 담아서 호출한다. 응답결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환한다. 반환시 view의 논리적인 이름("new-form")을 지정하고 실제 물리적인 이름은 프론트 컨트롤러에서 처리한다.
// FrontControllerServletV3의 메소드 일부
@Override
protected void service(HttpServletRequest request, HttpServletResponseresponse)
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);
}
// HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다.
// 해당 Map(paramMap)을 컨트롤러에 전달하여 호출
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");
}
뷰 리졸버
MyView view = viewResolver(viewName)
-> 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환.
view.render(mv.getModel(), request, response)
-> 뷰 객체를 통해서 HTML 화면을 렌더링 한다. 뷰 객체의 render() 는 모델 정보도 함께 받는다.
-> JSP는 request.getAttribute() 로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute() 로 담아둔다. JSP로 포워드 해서 JSP를 렌더링 한다.
v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실 제 컨트톨러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 번거롭다.
V4. 단순하고 실용적인 컨트롤러
기본적인 구조는 V3와 같다. 대신에 컨트롤러가 ModelView 를 반환하지 않고, ViewName만 반환
이번 버전은 인터페이스에 ModelView가 없다. model 객체는 파라미터로 전달되기 때문에 모델을 직접 생성하지 않아도 됨, 결과 로 뷰의 이름(return "new-form")만 반환해주면 된다.
public interface ControllerV4 {
/**
* @param paramMap
* @param model
* @return viewName
*/
String process(Map<String, String> paramMap, Map<String, Object> model);
}
프론트 컨트롤러 service() 메소드에서 모델 객체를 전달한다. 모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다. 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.
Map<String, Object> model = new HashMap<>(); //추가
// 컨트롤러가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.
String viewName = controller.process(paramMap, model);
MyView view = viewResolver(viewName);
기존 구조에서 모델을 파라미터로 넘기고, 뷰의 논리 이름을 반환한다는 작은 아이디어를 적용했을 뿐인데, 컨트롤러를 구현하는 개발자 입장에서 보면 이제 군더더기 없는 코드를 작성할 수 있다.
V5. 유연한 컨트롤러
어떤 개발자는 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());
//V4 추가 -> 기능을 확장해도 코드 변경 필요없다. 관련 추가만 하면 됨 (역할(interface)과 구현의 분리, OCP 지킴)
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());
//V4 추가
handlerAdapters.add(new ControllerV4HandlerAdapter());
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Object handler = getHandler(request); //url에 매핑된 핸들러(컨트롤러) 객체를 반환
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);
}
어댑터의 handle(request, response, handler) 메서드를 통해 실제 어댑터가 호출된다. 어댑터는 handler(컨트롤러)를 호출하고 그 결과를 어댑터에 맞추어 반환한다.
// ControllerV4HandlerAdapter와 ControllerV3HandlerAdapter의 코드 중 어댑터 호출
ModelView mv = adapter.handle(request, response, handler);<정리>
v1: 프론트 컨트롤러를 도입 기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입
v2: View 분류 단순 반복 되는 뷰 로직 분리
v3: Model 추가 서블릿 종속성 제거 뷰 이름 중복 제거
v4: 단순하고 실용적인 컨트롤러 v3와 거의 비슷 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
v5: 유연한 컨트롤러 어댑터 도입 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계