모델 2 방식과 스프링 - accidentlywoo/legacyVue GitHub Wiki

모델 2 방식과 스프링

모델 2 패턴의 이해

가장 핵심적인 내용은 '화면과 데이터 처리를 분리해서 재사용이 가능하도록 하는 구조' 모델 2 구조에서는 다음과 같은 용어들이 사용된다.

모델(Model) : 데이터 혹은 데이터를 처리하는 영역을 의미한다.
뷰(View) : 결과 화면을 만들어 내는 데 사용하는 자원을 의미한다.
컨트롤러(Controller) : 웹의 요청(Request)을 처리하는 존재로 뷰와 모델 사이의 중간 통신 역할을 한다.

모델 2에서 모든 요청은 기본적으로 컨트롤러를 호출한다. 각 컨트롤러는 자신을 호출하는 특정한 URI 경로를 가지고 있다. 과거에는 주로 호출 시에 마지막 확장자를 '*.do' 등을 이용하는 방식을 많이 사용.

모델 2 방식은

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

모델 2에서 Front Controller 패턴으로

모델 2 방식이 개발자와 웹 퍼블리셔 간의 분업을 이루는 데는 성공했지만, 각 컨트롤러사이의 중복적인 코드의 문제와 개발자의 개발 패턴의 차이 등의 문제로 인해 모델 2 방식은 좀 더 강제적인 형태인 Front Controller 방식을 적용한다.

Front Controller 패턴의 가장 중요한 변화는 전체 로직의 일부만을 컨트롤러가 처리하도록 변경되었다는 점.흔히 '위임(Delegation)'이라고 하는데, 전체로직의 일부를 컨트롤러에게 위임하고 모든 흐름의 제어는 앞쪽의 Front Controller가 담당하게 된다.

위와 같은 구조를 사용하게 될 경우 개발자가 작성하는 컨트롤러는 전체 로직의 일부분만을 처리하는 형태가 되기 때문에 개발자가 작성해야 하는 전체 코드는 줄어들게 된다.또한, 모든 컨트롤러는 Front Controller의 일부분을 구현하는 형태이므로, 좀 더 규격화된 코드를 작성하게 된다.

스프링 MVC의 구조

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

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

스프링 MVC를 사용하면 개발의 전체 흐름은 개발자가 제어하지 않고 개발자는 필요한 부품을 끼워 넣는 형태의 작업을 하게 된다.스프링 MVC의 경우에는 이 부품이 컨트롤러가 된다.

스프링 MVC의 컨트롤러

스프링 MVC를 공부하는 데 있어서 필구적인 내용은 컨트롤러를 어떻게 만들고, 처리하는가이다. 우선 가장 중요한 질문인 '스프링 MVC의 컨트롤러가 무엇을 처리해 주는가?'에 대해서 다음과 같이 정리할 수 있다.

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

스프링 MVC 컨트롤러는 기존의 다른 프레임워크와 비교하면 구성 방식에서 독측한 점이 많다.컨트롤러는 다음과 같은 점이 기존 Java 코드에 비해서 독특하게 느껴진다.

스프링 MVC 컨트롤러는 상속이나 인터페이스를 구현하지 않아도 된다. 기존의 프레임워크들과는 달리 스프링 MVC에서는 컨트롤러 작성 시 아무런 제약이 없다. 그대신 해야 하는 작업은 '@Controller'라는 애노테이션에 대한 추가 작업이다.
메소드의 파라미터와 리턴 타임에 대한 제약이 없다. 클래스가 특정 부모 클래스나 인터페이스가 없으니 메소드에 대한 제약도 존재하지 않다. 이후의 예제를 통해 살펴보겠지만 파라미터 타임과 리턴 타입에 대한 제약이 없는 관계로 기존보다 훨씬 자유로운 코드를 만들어 낼 수 있다.
스프링 MVC가 제공하는 유용한 클래스들이 존재한다. 스프링 MVC의 경우 다양한 클래스를 이용해서 필요한 작업을 수월하게 진행할 수 있다. 예를 들어 파일 업로드 처리나 유효성 검사 등을 제공하고 있기 때문에 개발자는 필요한 클래스를 이용해서 빠른 시간 내에 개발할 수 있다.

스프링 MVC에서 주로 사용하는 애노테이션의 종류

@Controller : 스프링 MVC의 컨트롤러 객체임을 명시하는 애노테이션 : 클래스
@RequestMapping : 특정 URI에 매칭되는 클래스나 메소드임을 명시하는 애노테이션 : 클래스, 메소드
@RequestParam : 요청(request)에서 특정한 파라미터의 값을 찾아낼 때 사용하는 애노테이션 : 파라미터
@RerquestHeader : 요청(request)에서 특정 HTTP 헤더 정보를 추출할 때 사용 : 파라미터
@PathVariable : 현재의 URI에서 원하는 정보를 추출할 때 사용하는 애노테이션 : 파라미터
@CookieValue : 현재 사용자의 쿠키가 존재하는 경우 쿠키의 이름을 이용해서 쿠키의 값을 추출 : 파라미터
@ModelAttribute : 자동으로 해당 객체를 뷰까지 전달하도록 만드는 애노테이션 : 메소드, 파라미터
@SessionAttribute : 세션상에서 모델의 정보를 유지하고 싶은 경우에 사용 : 클래스
@InutBinder : 파라미터를 수집해서 객체로 만들 경우에 커스터마이징 : 메소드
@ResponseBody : 리턴타입이 HTTP의 응답 메시지로 전송 : 파라미터
@Repository : DAO 객체 : 클래스
@Service : 서비스 객체 : 클래스