스프링 MVC 구조

스프링 MVC의 흐름은 아래와 같습니다.

1. 사용자의 모든 요청은 스프링 MVC의 Front Controller에게 전달된다.
2. 전달된 요청은 적절한 컨트롤러를 찾아서 호출한다.
3. 이때 사용되는 컨트롤러의 작업이 개발자의 몫이며 컨트롤러는 적절한 서비스 객체를 찾아 호출하고 서비스는 데이터 베이스의 작업을 담당하는 DAO(Data Access Object)를 이용해서 원하는 데이터를 요청한다.
4. DAO객체는 MyBatis를 이용하는 Mapper를 통해서 원하는 작업을 수행한다.
5. 서비스가 처리한 데이터를 컨트롤러에게 전달한다.
6. 컨트롤러는 다시 스프링 MVC쪽으로 데이터를 전달한다.

스프링 MVC가 처리해주는 작업	개발자가 직접 해야하는 작업
URI를 분석해서 적절한 컨트롤러를 찾는 작업 컨트롤러에 필요한 메소드를 호출하는 작업 컨트롤러의 결과 데이터를 뷰로 전달하는 작업 적절한 뷰를 찾는 작업	특정 URI에 동작하는 컨트롤러를 설계하는 작업 서비스 객체의 생성 DAO객체의 생성 컨트롤러 내에 원하는 결과를 메소드로 설계 뷰에서 전달받은 데이터의 출력

스프링 MVC의 컨트롤러는 무엇을 처리해줄까요?

• 파라미터의 수집 : 웹에서 가장 많이 하는 작업은 사용자의 요청에 필요한 데이터를 추출하고 이를 VO(Value Object) 혹은 DTO(Data Transfer Object)로 변환하는 파라미터의 수집 작업입니다. 스프링 MVC의의 컨트롤러는 이러한 처리를 자동으로 해주기 때문에 개발 시간을 크게 단축할 수 있습니다.
• 애노테이션을 통한 간편 설정 : 스프링 MVC의 설정은 크게 XML과 애노테이션을 사용할 수 있지만, 애노테이션을 사용하는 경우가 더 많습니다. 애노테이션을 사용하기 때문에 개발자는 클래스나 메소드의 선선언에 필요한 애노테이션을 추가하는 작업을 통해서 요청(request)이나 응답(response)에 필요한 모든 처리를 완료할 수 있습니다.
• 로직의 집중 : 기존의 모델 2는 특정한 URI마다 컨트롤러를 개발하는 경우가 많았지만 스프링 MVC 컨트롤러의 경우 각 메소드마다 필요한 애노테이션을 설정할 수 있기 때문에 여러 메소드를 하나의 컨트롤러에 집중해서 작성할 수 있습니다.
• 테스트의 편리함 : 스프링은 테스트 모듈을 사용해서 스프링 MVC로 작성된 코드를 WAS의 실행 없이도 테스트할 수 있는 편리한 방법을 제공합니다.

스프링 MVC 컨트롤러는 독특한 점이 많은데 기존 Java 코드에 비해서 독특한 점에 대해 알아봅시다.

• 스프링 MVC컨트롤러는 상속이나 인터페이스를 구현하지 않아도 컨트롤러 작성시 아무런 제약이 없습니다. 그대신 해야 하는 작업은 @Controller라는 애노테이션에 대한 추가 작업입니다.
• 메소드의 파라미터와 리턴 타입에 대한 제약이 없습니다. 클래스가 특정 부모 클래스나 인터페이스가 없으니 메소드에 대한 제약도 존재하지 않습니다.
• 스프릉 MVC가 제공하는 유용한 클래스들이 존재합니다. 파일 업로드 처리, 유효성 검사 등을 제공하고 있기 때문에 개발자는 필요한 클래스를 이용해서 빠른 시간 내에 개발할 수 있습니다.