Front Controller 패턴

복습

기존의 Servlet, JSP를 통한 MVC Pattern의 한계점을 복습해봅시다. (https://jaimemin.tistory.com/1815)

 

• 뷰 렌더링과 컨트롤러 역할을 분리한 건 좋지만 페이지가 늘어남에 따라 컨트롤러 내 중복 코드 다량 발생
• View로 이동하는 Forward 코드 중복 
• View 주소 즉, ViewPath 설정하는 코드 중복
• 별도 응답을 보낼 필요가 없는 경우 서블릿 내 response 코드가 사용되지 않음
• HttpServletRequest, HttpServletResponse를 사용하는 테스트 코드 작성하기 쉽지 않음
• 정리하자면, 공통 처리가 어려운 것이 문제 (이를 해결하기 위해 Front Controller 패턴 도입)

 

 

공통처리가 어려운 것이 문제

 

Front Controller의 특징

• 서블릿 하나로 클라이언트의 요청을 받음
• 프런트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
• 프런트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨
• 정리하자면, FrontController는 공통 코드를 처리하고 요청에 맞는 컨트롤러를 매핑해주는 역할 (앞서 언급한 Servlet, JSP를 통한 MVC 패턴의 단점 해결)
• ex) 스프링 웹 MVC의 DispatcherServlet

 

Front Controller를 도입한 결과

 

Front Controller가 제역할을 수행하도록 처리해줘야 하는 절차

1. Front Controller가 URL 매핑 정보에서 적합한 컨트롤러를 조회하여 호출하도록 처리

2. 기존에는 View로 이동하는 Forward 코드가 중복되었으므로 별도로 뷰를 처리하는 객체를 생성하여 컨트롤러에서 ModelAndView를 반환하면 Front Controller에서 렌더링 하도록 처리

3. Front Controller를 제외한 나머지 컨트롤러들은 서블릿 기술을 몰라도 동작될 수 있도록 처리 즉, 서블릿 종속성 제거

4. 뷰의 이름을 전부 명시하지 않고 논리 이름만 반환해도 되도록 처리 (ViewResolver 구현)

 

위 내용을 정리하자면 아래 그림과 같이 표현할 수 있습니다.

 

FrontController 도입 후

 

그림을 보면 공통적으로 처리해야하는 부분을 Front Controller에서 담당하기 때문에 기존 Servlet, JSP를 통한 MVC 패턴보다 훨씬 발전된 것처럼 보입니다.

하지만, 위 그림에도 한 가지 치명적인 단점이 있습니다. 바로, Front Controller가 한 가지 타입의 컨트롤러만 호출할 수 있다는 점입니다. 즉, 유연하지 못한다는 점입니다.

 

단점을 해결하기 위해서 도입해야할 어댑터 패턴

• 앞서 설명했드시 여태까지 설명한 Front Controller 패턴의 경우 한 가지 방식의 컨트롤러 인터페이스만 사용 가능합니다.
• 따라서, 여러 컨트롤러 인터페이스와 호환 가능하도록 프런트 컨트롤러와 컨트롤러 사이 어댑터를 배치해줘야 합니다.
• 김영한 강사님이 설명을 잘해주셨는데, A 컨트롤러 인터페이스와 B 컨트롤러 인터페이스가 있다고 가정한다면 각 인터페이스는 110V, 220V와 같이 비유할 수 있습니다. 이 둘을 모두 수용하기 위해서는 110V에 220V 돼지코 즉, 어댑터를 추가해줘야 합니다.

 

어댑터

 

어댑터 패턴을 도입한 MVC 패턴은 아래 그림과 같습니다.

 

어댑터 패턴을 적용한 MVC 패턴

 

* Handler는 Controller보다 넓은 개념, HandlerAdapter가 있기 때문에 Front Controller는 다양한 Handler를 처리할 수 있음

* HandlerAdapter를 추가함으로써 프레임워크를 유현하고 확장성 있게 설계할 수 있다는 것이 핵심

 

출처

인프런 스프링 MVC 1편 (김영한 강사님)