.png&blockId=3197e115-ee0d-4d9c-9f5d-4b57cb28634e)
Front Controller
•
서블릿 컨테이너 제일 앞단에서 서버로 오는 모든 요청을 받아 처리하는 컨트롤러
기존의 servlet
요청 url당 servlet을 생성하고 해당 controller 에게 요청을 보내는 코드를 따로 작성해야 했다
Front Controller 패턴
•
하나의 servlet에서 요청을 받아들여 적절한 controller로 요청을 위임한다
•
사용자의 요청에 대해 인코딩 처리, 에러페이지 처리, 공지 등에 대한 처리도 한 곳에서 처리할 수 있다
Dispatcher Servlet의 흐름
•
디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임합니다.
1.
요청 접수
web.xml에 설정된 url-pattern에 해당하는 경우 http request를 받는다
2.
컨트롤러로 요청 위임
url, method 같은 요청 정보를 참고해서 컨트롤러에게 작업을 위임
3.
컨트롤러에서 작업 진행
•
요청이 위임된 컨트롤러에서 작업을 진행
•
작업이 끝나면 다시 dispatcher servelt으로 결과를 반환
4.
뷰 호출
•
dispatcher servelt은 뷰에게 모델을 넘겨주며 최종 결과물을 생성
5.
최종 읍답
•
dispatcher servelt은 공통으로 진행해야 할 후처리 작업이 있는 지 확인 후 수행
•
수행 후 HttpServeltResponse에 있는 최종 결과를 서블릿 컨테이너에게 돌려주고 컨테이너는 클라이언트에 전송하여 응답
Dispatcher Servlet의 장점
•
url마다 Servlet을 매핑하지 않아도 된다
◦
모든 Request에 대해 1:1로 Servlet을 생성해주게 되면, 매핑 정보를 모두 기록해야 하는 web.xml 파일이 너무 복잡하고 커진다
•
주소마다 servlet이 있는 것이 아니라 하나의 servlet이 모든 request를 관리하기 때문에 공통적인 전처리, 후처리 작업을 할 수 있다
Dispatcher Servlet의 단점 보안
Dispatcher Servlet이 모든 요청을 처리하다보니 이미지나 HTML 등과 같은 정적 리소스에 대한 요청까지도 모두 가로채 정적 리소스를 불러오지 못하는 상황도 발생하곤 했다
두 가지 방안
1. 정적 리소스에 대한 요청과 어플리케이션에 대한 요청 분리
•
클라이언트의 요청을 두 타입으로 분리하는 것이다
•
/apps 의 URL 로 접근할 경우 디스패처 서블릿이 처리를 담당
•
/resources 의 URL 로 접근할 경우 디스패처 서블릿이 컨트롤할 수 없는 요청이므로 담당하지 않음
•
이러한 방식은, 앞서 언급한 문제는 해결할 수 있지만 소스 코드가 상당히 지저분해지며 모든 요청에 대해 /apps 나 /resources URL 을 붙여야 하므로 직관적인 설계가 될 수 없다.
2. 어플리케이션에 대한 요청을 탐색하고, 없을 경우 정적 리소스에 대한 요청으로 처리
•
모든 요청에 대해 디스패처 서블릿이 적합한 컨트롤러를 탐색하고, 해당 요청에 대한 컨트롤러를 찾을 수 없는 경우에 2차적으로 설정된 정적 리소스 경로를 탐색해 리소스를 찾는 방식
•
이렇게 영역을 분리하면 효율적인 리소스 관리가 가능할 뿐 아니라 추후에 확장이 용이하다는 장점을 가지게 된다
