스프링 MVC 1편 - MVC 프레임워크

MVC 프레임워크

• 프론트 컨트롤러 패턴

클라이언트1 → ControllerA

클라이언트2 → 공통(FrontController) → ControllerB

클라이언트3 → ControllerC

FrontController가 요청에 맞는 Controller를 찾아서 호출

Front만 서블릿을 사용하면 됨

FrontController urlPatterns에 /v1/* 로 설정하여 /v1 하위 uri는 모두 통하도록 구조 변경함

View 분리

• level1

FrontController에서는 로직Controller만 호출함. 로직 처리하는 Controller에서 직접 렌더링하여 JSP 반환해줌.

• level2

viewPath 설정 후 dispatcher.forward()를 처리하는 객체를 따로 만들어 FrontController에서 처리하도록 변경함

• level3

로직컨트롤러의 HttpServletRequest, HttpServletResponse 제거, request→Model로 변경

→ 컨트롤러가 서블릿 기술을 사용하지 않게 변경함

FrontController에서만 request, response를 사용하고 로직 컨트롤러들은 파라미터만 Map으로 받아 결과(Model)만 리턴함.

FrontContrller → 로직Controller → Model → 렌더링해 JSP반환

→ 뷰 이름의 중복을 제거함

• level4

컨트롤러의 반환값을 ModelView → viewName으로 변경

controller 인터페이스의 process 메소드에 model 파라미터를 추가함. 구현부에서는 파라미터로 넘어온 빈껍데기인 모델에 값을 넣고 viewName만 리턴함.

• level5

어댑터 패턴 → level3, 4의 FrontControlelr 방식을 혼용할수있게 변경

FrontController의 생성자에서 controllerMap에 직접 Controller 목록을 넣었었는데, 어댑터를 타서 모델뷰를 반환하도록 수정

FrontController → handleMap에 Controller가 있는지 찾음(getHandler) → 존재시 해당 Controller(getHandlerAdapter)의 process처리(handle) → ModelView 반환 → viewResolver가 View반환 → JSP로 응답

V4를 추가할때도, 어댑터에서 ModelView를 반환하면 됨.

여기서 더 나아가… 인터페이스와 구현을 더 분리해서 설계해보자

스프링 MVC가 이와 유사한 구조를 가지고 있음!

ex) @requestMapping → requestMappingHandlerAdapter

• 단축키

option + command + M → 메소드 생성(메소드 내에서 로직 레벨 맞추자!)

command + O → 파일명으로 class 찾기