카페에서 공부함

내용이 너무 많을시 집에가서 간추려서 편집해야겠음

스프링 MVC 기본사상

Java를 이용하는 웹 애플리케이션 제작 경험이 있다면 Servlet/JSP 기술을 활용해서 제작하는 방식을 먼저 배움.
이후 모델2라는 방식을 학습함 스프링 MVC의 경우 이러한 부분을
개발자들에게 보여주지 않고, 개발자들은 자신이 필요한 부분을 집중적으로 개발할 수 있는 구조로 만들어짐.

기존방식

웹프로그래밍을 배워본 적이 있다면 가장 익숙한 단어들중 하나는 Request/Response이며 Servlet/JSP에선 HttpServletRequest/HttpServletResponse라는
타입의 객체를 이용해서 브라우저에서 전송한 정보를 처리

스프링 MVC의 방식

스프링 MVC의 경우 이 위에 하나의 계층을 더한 형태임
스프링 MVC를 이용하게 되면 개발자들은 직접적으로 HttpServletRequest/HttpServletResponse등
Sevlet/JSP의 API를 사용할 필요성이 줄어듬.
**스프링은 중간에 연결 역할을 하기 때문에 이런 코드를 작성하지 않고도 원하는 기능을 구현함 **

개발자의 코드는 스프링 MVC에서 동작하기 때문에 스프링 2.5버전 전에는
특정한 클래스를 상속하거나 인터페이스를 구현하는 형태로 개발했지만,
2.5버전 이후부터 등장한 어노테이션방식으로 인해
최근 개발에는 어노테이션과 XML등의 설정만으로 개발이 가능하짐

모델 2와 스프링 MVC

위 내용에서 보여주듯이 스프링 MVC 역시 내부적으로는 Servlet API를 활용함. 스프링 MVC는 모델 2라는 방식으로 처리되는 구조이므로
모델 2방식에 대해서 간단히 살펴볼 필요가있음

모델 2(Model 2)

모델 2방식은 쉽게 말해서 로직과 화면을 분리하는 스타일의 개발 방식임

모델 2방식에서 사용자의 Request는 특별한 상황이 아닌 이상 먼저 Controller를 호출
이렇게 설계하는 가장 중요한 이유는
나중에 View를 교체하더라도 사용자가 호출하는 URL자체에 변화가 없게 만들어 주기 때문임.
컨트롤러는 데이터를 처리하는 존재를 이용해서 데이타(Model)을 처리하고 Response
할 때 필요한 데이터(Model)를 View 쪽으로 전달하게 됨.
Servlet을 이용하는 경우 개발자들은 Servlet API의 RequestDispatcher등을 이용해서
이를 직접 처리해 왔지만 스프링 MVC는 내부에서 이런 처리를 하고,
개발자들은 스프링 API를 이용해서 코드를 작성하게됨.

스프링 MVC의 기본구조 (그림은 개정판 122p참고)

1. 사용자의 Request는 Front-Controllerdls DispatcherServlet을 통해서 처리함.
   생성된 프로젝트의 web.xml을 보면 모든 Request를 DispatcherServlet이 받도록 처리하고 있음.

2. (2&3)HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해 존재함,
   HandlerMapping 인터페이스를 구현한 여러 객체들 중 RequestMappingHandlerMapping같은
   경우는 개발자가 @RequestMapping 어노테이션이 적용된 것을 기준으로 판단함.
   적절한 컨트롤러가 찾아졌다면 HandlerAdapter를 이용해서 해당 컨트롤러를 동작시킴.

3. Controller는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성하게 됨.
   이때 View에 전달해야 하는 데이터는 주로 Model이라는 객체에 담아서 전달함.
   Controller는 다양한 타입의 결과를 반환하는데 이에 대한 처리는 ViewResolver를 이용함.

4. ViewResolver는 Controller가 반환한 결과를 어떤 View를 통해서 처리하는 것이 좋을지
   해석하는 역할을함
   가장 흔하게 사용하는 설정은 servlet-context.xml에 정의된InternalResourceViewResolver임

5. (6&7)View는 실제로 응답 보내야 하는 데이터를 Jsp등을 이용해서 생성하는 역할을함
   만들어진 응답은 DispatcherServlet을 통해서 전송됨.

Front-Controller 패턴

122p의 그림을 참고하면
모든 Request는 DispatcherServlet을 통해서 설계되는데, 이런방식을 Front-Controller 패턴이라고 함. Front-Controller 패턴을 이용하면 전체 흐름을 강제로 제한할 수 있음.

예를 들어 HttpServlet을 그대로 상속해서 만든 클래스를 이용하는 경우 특정 개발자는
이를 활용할 수 있지만 다른 개발자는 자신이 원래 하던 방식대로 HttpServlet을
그대로 상속해서 개발할 수도 있음
Front-Controller 패턴을 이용하는 경우에는 모든 Request의 처리에 대한 분배가
정해진 방식대로만 동작하기 때문에 좀 더 엄격한 구조를 만들수있음.

스프링 MVC의 Controller

• 스프링 MVC Controller의 특징
• • HttpServletRequest, HttpServletResponse를 거의 사용할 필요 없이 필요한 기능 구현