MVC
애플리케이션의 역할을 모델(model), 뷰(view), 컨트롤러(controller)로 나누어 작업을 분담
업무 서비스(business service)와 도메인 객체(domain object)를 사용자 인터페이스(user interface)로부터 분리시켜 하나 이상의 컨트롤러를 통해서 이들 사이의 상호작용을 통재하는 아키텍처 패턴(architectural pattern)
주의 해야 될 점은 MVC 패턴은 고정적인 아키텍처 패턴이 아닌 조금씩 변화되며 MVC 패턴이라 해도 모두 다 똑같은 구조를 띄진 않음
- 기존의 Model 내에 비즈니스 로직이 함께 포함되어 있는 경우에서 현재 분리 되어 있는 MVC 패턴을 주로 사용되는 것처럼 계속해서 변화하며 경계선이 모호하다는 것 참고
Model
애플리케이션의 핵심적인 기능 제공
뷰와 컨트롤러 등록
- 데이터 변경 시 뷰와 컨트롤러에 통지
데이터와 데이터를 처리하는데 필요한 메서드를 포함한다
View
컨트롤러를 생성하고 초기화, 사용자에게 정보 표시
모델로부터 데이터 읽어와 처리
JSP로 구현되며 컨트롤러가 제공한 모델을 사용하여 데이터를 엑세스해 뷰를 렌더링하여 응답을 생성하고 컨트롤러로 전달한다
Controller
사용자의 입력을 이벤트로 받아 해당 이벤트 해석 후 모델에 대한 요청을 서비스하거나 뷰에 대한 요청을 표시
일반적으로 서블릿으로 구현된다
구체적으로 시작 접속점(contact point)으로서 인증과 권한과 같은 보안 서비스를 호출하고, 업무 처리 위임, 적절한 뷰 선택 관리, 에러 처리, 컨텐츠 생성 전략 선택 관리 등 요청을 처리하는 것을 관리
업무 로직은 컨트롤러에서 처리하므로 모델은 자신이 관리하는 데이터만 처리하는데 집중
서블릿, servlet
웹 서버에서 실행되는 작은 자바 프로그램으로 웹 클라이언트로부터 HTTP 요청을 수신하여 반응하는 프로그램
Dispatcher
뷰의 관리와 이동에 대한 책임을 갖는다
- 사용자에게 다음에 보여줄 뷰의 선택을 관리하며, 이 리소스로 제어를 인도하는 메커니즘을 제공한다
컨트롤러와 뷰, 모델 사이의 위치해 조율
Helper
컨트롤러, 디스패처, 뷰와 연결되어 작업 처리를 완료할 수 있도록 도와주며 뷰에서 필요한 데이터를 수집해 모델에 저장하는 등의 다양한 책임을 가짐
Business Service
헬퍼는 비즈니스 서비스와 연결되어 있는데 이 비즈니스 서비스는 업무 처리를 위한 로직을 담당한다
간략한 전체 구조
현재 주로 사용되고 있는 MVC의 구조
컨트롤러 : 요청에 대한 분기점으로 서블릿을 이용해 구현된다
뷰 : 여기서 뷰는 JSP를 의미하며 생성, 갱신 된 모델에 접근해 화면에 표시한다
서비스 컴포넌트 : 애플리케이션 퍼사드(facade)로서 역할을 하며 관련된 레파지토리 컴포넌트를 호출하여 데이터 액세스 로직을 제공하며 과거의 MVC 패턴에서 모델의 실질적인 역할을 수행
퍼사드(facade): 클래스 라이브러리 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 간략화된 인터페이스를 제공하는 객체
구체적인 구조
위에서 언급한 것은 간단한 Model, Controller, View의 구조이며 여기선 실질적인 MVC 운영과 관련한 구조를 설명
프론트 컨트롤러 : 디스패처 서블릿으로 클라이언트의 모든 요청을 받고 요청에 맞는 컨트롤러로 요청을 전달해주는 역할, 이 때 선정된 컨트롤러에 HTTP 요청을 위임한다
핸들러 매핑: 요청에 맞는 컨트롤러를 선정해주는 역할뷰 리졸버: 논리적인 뷰를 물리적인 뷰와 매핑해주는 역할
컨트롤러, 서비스 컴포넌트, 레파지토리 컴포넌트 : 도메인, 요청에 따라 여러 개 존재
2번 요청의 응답 : 컨트롤러는 3, 4, 5 작업의 응답을 프론트 컨트롤러의 전달하며 이 때 조회, 가공한 모델과 논리적인 뷰를 반환한다
6번 요청 : 프론트 컨트롤러는 모든 요청의 대한 결과를 뷰에 전달하며 이 때 뷰 리졸버를 통해 매핑된 물리적인 뷰와 조회, 가공한 모델을 전달
뷰 : 최종 6번 요청에 따라 전달 받은 모델을 물리적인 뷰에 랜더링하며 클라이언트의 최초 요청을 처리 완료시킨다
onStartup()
Spring MVC Application 시작할 때 호출되는 메서드로 메서드 내에서 웹 애플리케이션 컨텍스트를 생성한 후 디스패처 서블릿을 등록하고 초기화하는 작업을 수행하는 메서드
생성 방법
- 빈 설정 클래스 이용
- XML 설정 파일 이용
- 그루비(gROOVY) 빈 정의 DSL을 사용
DispatcherServlet
HttpServlet 클래스에서 파생되는 서블릿으로 매핑된 URL의 모든 HTTP 요청을 처리
각 DispatcherServlet은 자기 자신의 웹 애플리케이션 용 IoC 컨테이너인 웹 애플리케이션 컨텍스트(WebApplicationContext)가 생성된다
- 웹 애플리케이션 컨텍스트는 스프링 MVC 애플리케이션에 필요한 스프링 빈의 인스턴스 생성하고 관리
- 뿐만 아니라 HTTP 요청을 컨트롤러와 매핑시켜주는
핸들러 매핑, 물리적인 뷰를 결정하는뷰 리졸버도 포함된다
DispatcherServlet을 이용해 웹 애플리케이션 용 IoC 컨테이너를 생성하고 이 컨테이너는 Spring MVC에 필요한 Bean 뿐만 아니라 핸들러 매핑, 뷰 리졸버도 관리
IoC 컨테이너의 애플리케이션 컨텍스트의 경우 트리 구조의 계층적인 구조를 가질 수 있으며 부모 애플리케이션의 컨텍스트를 가질 수 있고 컨텍스트 내부에서 각자 독립적인 설정 정보를 사용하여 스프링 빈 객체를 생성하고 관리할 수 있다
- 현재 컨테이너 내부에 스프링 빈이 없는 경우 부모 애플리케이션 컨텍스트에게 스프링 빈을 찾아달라 요청하며 계층적인 구조를 따라 올라간다
IoC를 관리하는 컨텍스트도 부모 자식 관계가 존재, 하지만 스프링 빈을 못찾는 과정에서 형제 컨텍스트에 요청을 하진 않는다(수직 관계만 유의미)
- 루트 웹 애플리케이션 컨텍스트를 시작으로 여러 개의 웹 애플리케이션 컨텍스트를 가질 수 있고 루트 웹 애플리케이션 컨텍스트는 여러 개의 웹 애플리케이션 컨텍스트의 공통적으로 사용되는 스프링 빈들이 정의되는 것이 일반적
- 하지만 특별한 설정이 되어 있지 않은 경우
@ComponentScan애너테이션을 통해 루트 웹 애플리케이션 컨텍스트와 자식 웹 애플리케이션 컨텍스트에 동일한 스프링 빈이 중복되어 등록되는데 이를 방지하기 위해 스프링 빈의 경로를 지정하며 방지할 수 있다
ComponentScan
ComponentScan을 사용할 때 useDefaultFilters, includeFilters, excludeFilters 등의 조건들을 사용해 바로 위에서 언급한 상황을 방지하며 스프링 빈 등록과 관련해 추가적인 설정들을 다룰 수 있다
