10월 27일 목요일 [코드로 배우는 스프링웹프로젝트] -2day(2)

PART2. 스프링 MVC 설정

스프링 프레임워크가 가장 많이 활용되는 Web관련 개발 환경과 라이브러리 설정에 대한 내용으로 진행

스프링MVC라고 불리는 웹 관련 스프링 라이브러리는 최근 웹 개발에서 필수적으로 사용되는 구조

기존의 Servlet/JSP 보다 간단하며, 빠르게 개발이 가능하기 때문에 인기가 많음

 

스프링 MVC의 기본 구조

스프링 MVC는 스프링의 서브(sub) 프로젝트 : 스프링은 하나의 기능을 위해서만 만들어진 프레임워크가 아닌, '코어'라고 할 수 있는 프레임워크에 여러 서브 프로젝트를 결합해서 개발됨

서브 프로젝트 = '별도의 설정이 존재할 수 있다

스프링MVC는 서브 프로젝트이기 때문에, 구성 방식이나 설정도 조금 다를 수 있음

책의 예제에서 만드는 구조

---

스프링 MVC 프로젝트의 내부 구조

스프링 MVC 프로젝트를 구성해서 사용한다는 의미

➡️ 내부적으로 root-context.xml로 사용하는 일반 Java 영역 + servlet-context.xml로 설정하는 Web 관련 영역을 연동해서 구동

 바깥쪽에 있는 WebApplicationContext : 기존 구조에 MVC 설정을 포함하는 구조로 만들어짐

스프링은 원래 목적 자체가 웹 애플리케이션을 목적으로 나온 프레임워크가 아니기 때문에, 달라지는 영역에 대해선 완전히 분리하고 연동하는 방식으로 구현됨

---

예제 프로젝트의 로딩 구조

프로젝트 구동 시 관여하는 XML : web.xml / root-context.xml / servlet-context.xml

web.xml : Tomcat 구동과 관련된 설정

root-context.xml & servlet-context.xml : 스프링과 관련된 설정

---

web.xml

<!-- The definition of the Root Spring Container shared by all Servlets and Filters -->
<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/spring/root-context.xml</param-value>
</context-param>
	
<!-- Creates the Spring Container shared by all Servlets and Filters -->
<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

* <context-param> : root-context.xml의 경로가 설정

* <listener> : 스프링 MVC의 ContextLoaderListener가 등록되어 있음

* ContextLoaderListener : 해당 웹 애플리케이션 구동 시 같이 동작

 

▲ root-context.xml이 처리되면 파일에 있는 빈(Bean) 설정들이 동작함

root-context.xml에 정의된 객체(Bean)들은 스프링의 영역(context)안에 생성 & 객체들 간의 의존성이 처리됨

 

 

▲ root-context.xml이 처리된 후에는 스프링 MVC에서 사용하는 DispatcherServlet과 관련된 설정이 동작함

'org.springframework.web.servlet.DispatcherServlet' 클래스 : 스프링 MVC 구조에서 가장 핵심적인 역할을 하는 클래스

- 내부적으로 웹 관련 처리의 준비작업을 진행 

- 이때 사용하는 파일이 servlet-context.xml : DispatcherServlet에서 XmlWebApplicationContext를 이용해서 servlet-context.xml을 로딩하고 해석하기 시작 => 이 과정에서 등록된 객체(Bean)들은 기존에 만들어진 객체(Bean)들과 같이 연동되게 됨

<!-- Processes application requests -->
<servlet>
	<servlet-name>appServlet</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring/appServlet/servlet-context.xml</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>
		
<servlet-mapping>
	<servlet-name>appServlet</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>

등록된 객체들이 기존에 만들어진 객체들과 연동됨

---

스프링 MVC의 기본 사상

스프링 MVC의 경우 개발자들이 자신이 필요한 부분만을 집중해서 개발할 수 있는 구조로 만들어져 있음

Servlet/JSP에서는 HttpServletRequest/HttpServletResponse라는 타입의 객체를 이용해 브라우저에서 전송한 정보를 처리하는 방식이다. 그러나 스프링 MVC의 경우 이 위에 하나의 계층을 더한 상태가 된다. 스프링 MVC를 이용하면 개발자들은 직접적으로 HttpServletRequest/HttpServletResponse 등과 같이 Servlet/JSP의 API를 사용할 필요성이 현저하게 줄어든다. 스프링은 중간에 연결 역할을 하기 때문에 이러한 코드를 작성하지 않고도 원하는 기능을 구현할 수 있게 된다. 개발자 코드는 스프링 MVC에서 동작하기 때문에 과거에는 특정한 클래스를 상속하거나 인터페이스를 구현하는 형태로 개발할 수 있었지만, 2.5버전 이후부터 어노테이션이 등장하여 최근엔 어노테이션이나 XML등의 설정만으로도 개발이 가능하게 되었다.

---

모델 2와 스프링 MVC

▲ 모델2 방식

쉽게 말해 '로직과 화면을 분리'하는 스타일의 개발 방식

모델 2 방식도 MVC의 구조를 사용

- 모델 2 방식에서 사용자의 Request는 먼저 Controller를 호출한다 : 나중에 View를 교체하게 되더라도 사용자가 호출하는 URL 자체에 변화가 없게 만들어주기 때문

- 컨트롤러는 데이터를 처리하는 존재를 이용해서 데이터(Model)을 처리

- Response할 때 필요한 데이터(Model)을 View 쪽으로 전달하게 된다

 

▲ 스프링 MVC 방식 ⭐️⭐️⭐️

스프링 MVC는 내부에서 Servlet API의 RequestDispatcher 처리를 하고, 개발자들은 스프링 MVC의 API를 이용해서 코드를 작성함

모든 Request는 DispatcherServlet을 통하도록 설계되어 있음 => Front-Controller 패턴

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

[1] 사용자의 Request는 Front-Controller인 DispatcherServlet을 통해서 처리함. 생성된 프로젝트의 web.xml을 보면 모든 Request를 DispatcherServlet이 받도록 처리한다.

[2][3] HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해서 존재한다. 적절한 컨트롤러를 찾으면, HandlerAdapter를 이용해서 해당 컨트롤러를 동작시킴

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

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

<beans: bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <beans:property name="prefix" value="/WEB-INF/views/"  />
    <beans:property name="suffix" value=".jsp" />
</beans:bean>

[6][7] View는 실제로 응답 보내는 데이터를 JSP 등을 이용해서 생성하는 역할. 만들어진 응답은 DispatcherServlet을 통해서 전송됨