스프링 @MVC의 편리함과 유연함은 지금까지 나온 어떤 MVC 방식의 프레임워크와 기술도 따라 올 수 없는 것이라고 생각한다. Controller의 계층구조에 존재했던 각종 컨트롤러 클래스들의 장점을 모두 모으고, 몇 배로 편리하게 사용할 수 있도록 만들어 놓은 것이 지금의 @MVC이다.

간단히 정리해보고 싶은 것은 @MVC의 컨트롤러 메소드에서 리턴하는 모델과 뷰 정보에 스프링이 자동으로 추가해주는 정보들이다. @MVC는 매번 번거롭게 ModelAndView를 만들어 리턴하지 않아도 되도록, 간단히 뷰 이름, 모델 맵, 단독 모델 오브젝트 등의 리턴 타입을 허용한다. 이 때 다음 4가지 종류의 오브젝트는 모델에 자동으로 추가된다.

1. @ModelAttribute 또는 커맨드 오브젝트

@MVC 메소드는 String add(@ModelAttribute User user) 또는 String add(User user) 라고 빈 스타일의 오브젝트를 통해서 파라미터나 폼 데이터를 전달 받을 수 있다. 보통 후자는 전통적인 이름을 따서 커맨드 오브젝트라고 부르고, 전자는 모델 애트리뷰트라고 부르지만 사실 내부적으로는 똑 같이 취급된다.

이 모델 애트리뷰트/커맨드 오브젝트는 자동으로 모델 맵에 추가된다. 따라서 따로 모델에 넣어줄 필요가 없다.

2. Map/Model/ModelMap

메소드 파라미터에 위의 세가지 중 한가지 타입을 넣었다면 모델 맵을 따로 생성할 것 없이 파라미터로 받은 오브젝트에 직접 모델을 추가해주면 된다. 당연하게도 이 파라미터에 넣은 모델 오브젝트는 컨트롤러가 리턴하는 모델이 된다. 흥미로운 점은 만약 메소드에서 리턴 값을 ModelAndView나 Model, 또는 단독 모델 오브젝트(String 타입이 아닌 단순 오브젝트는 그 자체로 하나의 모델 값으로 인식된다) 같은 것을 써서 모델 정보를 리턴한다고 하더라도, 이 파라미터 모델 맵의 정보가 무시되는 것이 아니다. 모두 최종적인 모델에 머징된다.

3. @ModelAttribute 메소드

MVC 시절 referenceData() 메소드와 같은 역할을 하는 @ModelAttribute를 메소드 레벨에 부여한 메소드가 있다면 그 결과 값은 항상 나머지 모든 컨트롤러 메소드의 모델에 자동 추가된다. 보통 참조용 데이터, 예를 들면 리스트박스에 뿌리는 코드 값 같은 것에 주로 사용된다.

4. BindResult.모델 이름의 BeanPropertyBindingResult

만약 @ModelAttribute를 명시적으로 또는 암시적으로 사용했다면 모델에는 자동으로 그 바인딩 결과가 담긴 "org.springframework.validation.BindingResult.모델이름"의 오브젝트가 추가된다. 타입은 BeanPropertyBindingResult이다. 이 모델은 스프링의 폼 태그에서 바인딩 결과에 따라서 메시지를 출력하거나 할 때 참조하기 위해서 자동으로 넣어주는 것이다.

컨트롤러 메소드에 Errors나 BindResult 파라미터를 넣었는지 여부와는 상관없이 이 모델은 추가된다.

 

모델 말고 뷰도 생각해 보자면, 뷰 정보를 전혀 생성하지 않았을 경우에는 RequestToViewNameResolver 전략이 적용되서 자동으로 뷰 이름이 생성된다.

오늘의 퀴즈. 다음 메소드를 실행하고 나서 DispatcherSerlvet이나 뷰가 전달 받는 모델 맵에는 몇 개의 엔트리가 있을까?

 

@ModelAttribute(“ref”) String ref() { return “data”;}

@RequestMapping(“/add”) public void add(User user, Model model) {

   model.addAttribute(“mesg”, "ok”);

}

 

정답을 맞추면… 보너스를.

Related posts:

  1. Spring Expressions(SpEL)를 이용한 Mockito Argument Matcher 만들기
  2. Spring 3.0 (41) @Deprecated SpringMVC
  3. Spring 3.0 (26) Spring Expression Language와 @Value
  4. [토스3] 스프링 JDBC DAO에 lazy-loading 적용하기 (2)
  5. Spring 3.0 (8) Core 모듈의 선택 라이브러리 분석
  6. Spring 3.0 (52) 반쪽짜리 3.0 RC1 공개
  7. Spring 3.0 (14) Context Support 모듈의 선택 라이브러리 분석
  8. Inside Spring (5) PropertyPlaceholderConfigurer를 @Bean으로 정의해서는 안되는 이유
  9. Spring 3.0 (37) 스프링 모듈-라이브러리 의존관계 매트릭스 업데이트와 CTDD
  10. Spring 3.0 EL (Spel)을 이용한 AssertThrows 확장 (3)
  11. Spring 3.0 (53) Spring Dependency Matrix 업데이트
  12. Spring 3.0 (35) Spring 3.0 Reference Document 공개
  13. Spring 상식퀴즈 (1) – DI 태클하기
  14. [토스3] 스프링 JDBC DAO에 lazy-loading 기능 적용하기
  15. Spring 3.0 (7) Spring 3.0 Dependency Matrix

Facebook comments:

to “Spring 3.0 @MVC 메소드에서 자동으로 리턴 모델에 추가되는 것들”

  1. I often visit your page and have noticed that you don’t update it often. More frequent
    updates will give your site higher authority & rank in google.
    I know that writing articles takes a lot of time, but you can always help yourself with miftolo’s tools which will
    shorten the time of creating an article to a few seconds.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha