Spring MVC - Introduction to Spring Web MVC framework

스프링 웹 model-view-controller (MVC) 프레잉워크는 DispatcherServler을 중심으로 설계 되었다. DispatcherServlet은 구성된 핸들러 매핑으로 요청을 핸들러로 디스패치하고,  뷰 레졸루션, 로케일, 타임존, 테마 레졸루션, 파일 업로딩 지원들을 수행한다. 기본 핸들러는 @Controller와 @RequestMapping 어노테이션을 기반으로 하고, 유연한 핸들링 방법을 제공한다. Spring 3.0의 소개로 @Controler 메커니즘은 @PathVariable과 다른 기능들로 RESTful Web sites 및 어플리케이션을 만드는 것을 지원한다. 

확장에 열려있다. 스프링 웹 MVC와 Spring에서 가장 중요한 원칙은 Open-Closed principle이다. 

Spring Web MVC에 핵심 클래스의 몇몇의 메소드는 final로 지정되어 있다. 때문에 개발자는 자신의 행위에 따라 이러한 메소드를 오버라이드할 수 없다. 이것은 임의로 수행할 수 없지만 특별히 이 원칙을 준수하도록 하자.

Spring MVC를 사용하면 final 메소드에 어드바이스를 추가할 수 없다. 예를 들어 AbstractController.setSynchrnoizeOnSession()에 어드바이스를 추가할 수 없다. AOP부분을 프록시 부분을 살펴보면 final 메소드에 advice를 추가할 수 없는 이유를 알 수 있다. 

스프링 MVC에서 커맨드 또는 form-backing 오브젝트를 사용할 수 있다. 프레임웍에서 명시한 인터페이스 또는 베이스클래스를 구현할 필요가 없다. 스프링의 데이터 바인딩은 매우 유연하다. 예를 들면 타입 불일치를 시스템 오류가 아닌 어플리케이션에서 평가하여 validation errors로 다룬다. 그러므로 단순하게 비즈니스 객체의 프로퍼티로 복제할 필요 없고, 유효하지 않은 타입이 없는 문자열로 처리할 수 있다. 또한 직접적으로 비즈니스 오브젝트에 바인딩할 수도 있다.

스프링의 뷰처리는 굉장히 유연하다. Controller는 일반적으로 데이터의 모델 맵을 준비하고 view 명을 선택한다. 그러나 도한 응답 트림으로 직접 결과를 작성하거나 요청을 완료한다. 뷰 처리는 파일 확장자 및 컨텐트 타입에 따라 설정할 수 있고 빈 이름, 프로퍼티 파일, ViwResolver 구현등을 지원한다. 모델은 맵 인터페이스이며 뷰 기술의 완전한 추상화이다. 템플릿 기반의 뷰 렌더링 기술(JSP, Velocity, Freemarker)과 연계할 수 있으며 XML, JSON, Atom등 직접 컨텐츠 타입 생성을 할 수 있다. 모델 맵은 단순하게 포맷 JSP request 어트리뷰와 같은 적절한 포맷으로 변경된다.

Features of Spring Web MVC 

스프링의 웹 모듈은 많은 유니크한 웹 지원 기능을 포함하고 있다. 

• 역할의 명백한 분리  각 역할 controller, validator, command object, form object, model object, DispatcherServler, handler mapping, view resolver 등등 특별한 오브젝트들을 구성되어 있다.

• 프레임워크와 JavaBeans와 같은 어플리케이션을 위한 강력하고 직관적인 설정. 이러한 설정은 컨텍스트간 쉬운 참조를 가능하게 한다. 엡 컨트롤러로 부터 비즈니스 오브젝트 밸리데이터간의 

• Adaptability, non-intrusiveness, and flexibility. 시나리오를 위해 파라미터 어노테이션(@RequestParam, @RequestHeader, @PathVariable) 중 하나를 이용하여 필요한 메소드 시그니처를 컨트롤러에 정의하라.

• Reusable business code,no need for duplication. 특정 프레임워크 기반 클래스를 확장하려고 해당 클래스를 복제하는 대신에 존재하는 비지니스 객체를 커맨드 객체나 폼 객체로 사용해라.

• Customizable binding and validation. 타입 미스 매치를 어플리케이션 레벨 검증 오류로 처리. 제공된 값을 유지하고, 로컬라이즈 날짜와 넘버 바인딩 그리고 스트링으로 구성된 폼 오브젝트의 매뉴얼 파싱이 아닌 비즈니스 오브젝트 변환

• Customizable handler mapping and view resolution. 핸들러 매핑 및 뷰 처리 전략은 단순한 URL 기반 설정으로 부터 더 정교한 목적 기반 전략등으로 설정할 수 있다. 스프링은 다른 web MVC 프레임워크에서 준수해야할 맨댄토리보다 더 유연하다.

• Flexible model transfer. name/value 맵의 모델 전송은 다른 view 기술과 쉽게 통합할 수 있다.

• 커스터마이징 로케일, 타임존, 테마 처리, JSTL 지원 Velocity 지원, Spring 태그 라이브러리 지원

• A simple yet powerful JSP taglibrary known as the Spring taglibrary that provides support for features such as data binding and themes. 커스텀 태그를 최대한 제공한다.

• Spring 2.0에서 소개된 JSP페이지를 더욱 쉽게 만들기 위한 JSP 폼 태그라이브러리 지원,

• HTTPRequest 또는 HTTPSession 스코프 지원을 위한 빈 라이프 사이클 

Pluggability of other MVC implementations

어떤 프로젝트에서는 Spring MVC를 선호하지 않을 수 있다. 많은 팀의 전문가들은 기 존재하는 기술이나 툴들을 활용하려고 할 것이다. 

만약 Spring 웹 MVC를 사용하지 않기를 원한다면 쉽게 스프링과 원하는 web MVC 프레임워크와 쉽게 연계할 수 있다. ContestLoaderListener로 스프링 루트 어플리케이션 컨텍스트를 구동하고 ServletContext 속성으로 어플리케이션 컨텍스트에 접근하라. 플러그인이 없으므로 전용 통합도 필요없다. 웹계층의 뷰에 진입점에서 루트 어플리케이션 인스턴스를 라이브러리처럼 사용할 수 있다.

등록된 빈들과 스프링 서비스는 스프링 웹 MVC가 없어도 이용 가능하단. 이러한 시나리오에서 스프링은 다른 웹 프레임워크가 경쟁하지 않는다. 웹 프레임워크가 아닌 영역에서 많은 기능을 제공한다. 그러므로 풍부한 스프링 미들 티어 및 데이터 엑세스 티어에 이용하고 싶은 많은 기능을 사용할 수 있다. 예를 들어 JDBC 또는 하이버네이트 추상화이다.