[Spring.4-1] Presentation Layer - MVC

Presentation Layer Presentation Layer

정의

속성/기술

Spring MVC 구조 Spring MVC 구조 Spring MVC는 Dispatcher Servlet을 중심으로 요청을 처리하는 구조이다.

1. Client = Browser.

브라우저는 Request를 보내고 Response를 기다린다. 브라우저는 ‘Engine’으로 구성되어있는데, Engine이 하는일은 크게 1) HTML DOM Parser, 2) JS Interpreter.
즉, Browser가 하는일은 HTML, JavaScript를 읽어서 HTML DOM Tree로 표현하고 화면에 뿌린다. DispatcherServlet이 client에 reponse를 줄 때에 Stream으로 String(HTML)을 쏴주고, 브라우저에서는 쏴준 HTML을 차례로 받아서 바로 DOM Tree를 그린다. 이 과정을 Rendering이라고 한다.
Client의 통신 방식에는 동기/비동기(AJAX)가 있다. 일반적으로는 동기 방식인데, 비동기 방식의 경우 Framework에서 소스코드 구성이 달라진다. 또한, Client가 받는 데이터 형태에는 Form/JSON이 있는데 JSON의 경우에도 Framework 환경을 달리 해주어야 한다.

2. 서블릿 컨테이너 생성

DispatcherServlet이 처음 요청됬을 때에 spring-config.xml(파일명은 달라질 수 있음) 설정파일을 참조하여 ApplicationContext(서블릿 컨테이너, 웹 컨테이너)를 생성. 기본적으로 LazyLoading이나 PreLoading설정을 할 수 있다. web.xml에 DispatcherServlet이 처리할 URL규칙을 명시해두면 해당 URL 규칙은 DispatcherServlet이 받아서 처리하게 된다.

3. HandlerMapping.

요청 URL에 맞는 ControllerMethod를 찾아준다. ‘search’의 역할을 하고 handler method를 반환한다.

4. HandlerAdapter.

해당 handler method를 ‘invoke’ 한다. 또한, invoke 시키기 전에 Client request의 데이터(파라미터)를 Command Object로 바인딩 시켜주는 ‘값변환’ 역할을 한다.

5~6. ModelAndView

HandlerAdapter에 의해서 Controller의 해당 Method가 invoke 되고 비즈니스 로직이 수행 된다. 비즈니스 로직 수행 후 ModelAndView를 DispatcherServlet에 반환한다. Model은 Map Interface를 구현한 객체로, 비즈니스 로직 수행 후의 결과 데이터를 model.addAttribute()로 Model 객체에 넣어서 보낸다. View는 ViewResolver에 의해 생성할 LogicalViewName, 즉 ViewTemplate의 이름이다. (ViewResolver를 사용하지 않을 경우 View 객체를 직접 반환할 수도 있다.)

7~8. ViewResolver.

Handler method가 invoke된 후 DispatcherServlet은 ModelAndView를 받고, ViewResolver에게 View(LogicalView, ViewTemplateName)를 전달한다. ViewResolver는 View에 해당하는 ViewTemplate과 Model을 resolve해서 View(HTML을 포함한 객체. HTML이라고 생각하면 됨)를 반환한다.

9. View

DispatcherSevlet은 View를 받아서 Client(Browser)에게 View(HTML)가 포함된 response를 준다.



- ExceptionResolver: Layer들의 에러를 공통적으로 처리해주는 ExceptionResolver클래스가 존재함. 기본적으로 100,200,300,400,500에러는 WEB에서 처리해주는 것이고, 스프링 내부의 에러를 에러코드로 변환해줌.
- 이렇게 Controller 까지를 HadlerMapping, HandlerAdapter, ViewResolver등 여러 부분으로 나누는 이유는 효율성 때문이다. 바로 Controller를 콜 하면 메모리를 많이 잡아먹음. 극단적으로, parameter 받은 데이터가 없으면 Controller를 호출할 필요가 없다. 중간에 여러 step을 둠으로써 효율화하고 커스터마이즈할 수 있는 장점이 있음.



기타 요소들

Interceptor

HandlerMapping에서 전후 처리를 지원하기 위한 모듈. Spring Interceptor 구현 객체로 HandlerInterceptorAdapter를 상속받은 Interface이고 preHandle, postHandle, afterCompletion 메소드가 있다. Controller invoke 전/후 또는 뷰 생성 후에 공통적으로 처리하려 하는 것을 구현할 수 있다. 예) Locale 설정, Session Interceptor

CustomArgumentResolver

HandlerAdapter에서 Controller Method의 arguments를 Customize하여 받을 때에 사용할 수 있다. 예) json으로 받거나 Map으로 받을 때

Message

유효성 검증