MVC 프레임워크

V1-프론트 컨트롤러 도입

FrontController 패턴 특징

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

V2-View 분리

• 모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고, 깔끔하지 않다.
• 이 부분을 해결하기 위해 별도로 뷰를 처리하는 객체를 만든다.
  
  

V3-Model 추가

서블릿 종속성 제거
컨트롤러 입장에서 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
  
  

ModelView
지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어본다.

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

• 논리 뷰 이름: members
• 물리 뷰 경로: /WEB-INF/views/members.jsp
• 뷰 객체를 통해서 HTML 화면을 렌더링한다.
• JSP는 request.getAttribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute()로 담아둔다.
• JSP로 포워드해서 JSP를 렌더링한다.
  
  
  
  

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

• v3를 조금 변경해 실용성있는 v4를 만든다.
• 기본적인 구조는 V3와 같지만, 컨트롤러가 ModelView를 반환하지 않고, ViewName만 반환한다.
  
  
  
  

V5-유연한 컨트롤러

어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 싶다면?

어댑터 패턴
지금가지 만든 버전은 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다. 호환이 불가능한 인터페이스는 어댑터를 통해 처리해야한다.

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

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

참고

• 김영한 스프링 로드맵
  (스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술)