스프링MVC 그리고 모델2방식

모델2패턴

화면과 데이터 처리를 분리해서 재사용이 가능하도록 하는 구조

개발자와 웹 퍼블리셔의 영역을 분리할 수 있으며, 컨트롤러의 URI를 통해서 뷰를 제어하기 때문에, 뷰의 교체나 변경과 같은 유지보수에 유용하게 사용될 수 있다.

모델 - 데이터 혹은 데이터를 처리하는 영역

뷰 - 결과 화면을 만들어 내는 데 사용하는 자원

컨트롤러 - 웹의 요청(request)을 처리하는 존재로 뷰와 모델 사이의 중간 통신 역할

 

Front Controller패턴

전체 로직의 일부를 컨트롤러에게 위임하고 모든 흐름의 제어는 앞쪽 스프링 MVC의 Front Controller가 담당한다.

이로인해 개발자가 작성하는 컨트롤러는 전체 로직의 일부분만을 처리하는 형태가 되며 작성해야하는 전체코드가 줄어들게 된다. 또한, 모든 컨트롤러는 Front Controller의 일부분을 구현하는 형태이므로, 좀 더 규격화된 코드를 작성하게 된다.

 

스프링 MVC가 처리해 주는 작업

URI를 분석해서 적절한 컨트롤러를 찾는 작업

컨트롤러에 필요한 메소드를 호출하는 작업

컨트롤러의 결과 데이터를 뷰로 전달하는 작업

적절한 뷰를 찾는 작업

 

개발자가 직접해야 하는 작업

특정 URI에 동작하는 컨트롤러를 설계하는 작업

서비스 객체의 생성

DAO 객체의 생성

컨트롤러 내에 원하는 결과를 메소드로 설계

뷰에서 전달받은 데이터의 출력

 

WAS없이 컨트롤러를 테스트하기

spring-test를 사용해서 실행할 때 가능하면 WAS의 Servlert스펙 버젼을 일치시키는 것이 좋다.

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>3.1.0</version>
</dependency>

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration(
		locations = {"file:sec/main/webapp/WEB-INF/spring/**/*.xml"})
public class SampleControllerTest {
	
	private static final Logger logger = LoggerFactory.getLogger(SampleControllerTest.class);

	@Inject
	private WebApplicationContext wac;
	
	private MockMvc mockMvc;
	
	@Before
	public void setup() {
		this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).build();
		logger.info("setup......");
	}
	
	@Test
	public void testDoA() throws Exception{
		mockMvc.perform(MockMvcRequestBuilders.get("/doA"));
	}
}

테스트 클래스 선언부에서는 @WebAppConfiguration 어노테이션을 사용하는데 이것이 기존의 스프링과 MVC를 테스트하는 데 있어서의 가장 큰 차이점이다.

MockMvc는 브라우저에서 요청과 응답을 의미하는 객체로 간주하면 된다.

매번 테스트를 진행할 때마다 가상의 요청과 응답을 처리하기 위해서 setup()메소드에서는 @Before 어노테이션으로 처리되어 매번 테스트 메소드이 실행 전에 MockMvc 객체를 만들어내게 된다.

testDoA()를 보면 MockMvcㄹ 사용해서 perform()메소드를 get()방식으로 호출하였다.