FrontController

Front Controller 패턴

 웹 애플리케이션의 진입점을 하나로 통합하여 공통된 처리 로직을 중앙 집중화 하는 디자인 패턴

주로 MVC 아키텍처에서 사용되며, 요청을 하나의 컨트롤러 (Front Controller)에서 받아 적절한 처리기로 위임하는 방식

---

핵심 개념

Front Controller는 모든 요청을 하나의 진입점에서 받아 처리

인증, 인가, 로깅, 에러 처리, 로케일 설정 같은 공통 기능을 이 중앙 컨트롤러에서 처리함

이후 실제 요청에 맞는 컨트롤러로 분기(Dispatch)

Client ──> FrontController ──> Dispatcher ──> Controller ──> View

 

구성 요소	설명
Front Controller	모든 요청을 받는 중앙 서블릿 (또는 핸들러)
Dispatcher	URI나 요청 정보를 기반으로 실제 컨트롤러에 분기
Handler / Controller	요청을 처리하는 구체적인 로직 담당
View Resolver	응답할 View를 선택하여 렌더링

---

 

장점

• 공통 기능을 한 곳에서 관리하므로 유지보수 용이
• 요청 흐름이 일관성 있게 제어
• 로깅, 인증 등 관심사의 분리 가능

단점

• 모든 요청이 하나의 컨트롤러로 들어오므로 복잡도 증가 가능
• 단일 장애 지점 (Single Point of Failure)이 될 수 있음

📌 프레임워크 적용 예시) Spring MVC의 `DispatcherServlet`

---

❓ FrontController ≠ Dispathcher ?

Front Controller 자체가 Dispatcher 역할을 수행하는 경우가 많음

개념적: Front Controller  = Dispatcher

대부분 프레임워크에서 FrontController가 Dispatcher 역할까지 수행

예시: Spring MVC의 DispatcherServlet

// DispatcherServlet 내부
doDispatch(HttpServletRequest request, HttpServletResponse response) {
    Handler handler = handlerMapping.getHandler(request);
    ModelAndView mv = handlerAdapter.handle(request, response, handler);
    viewResolver.resolveViewName(mv.getViewName()).render(...);
}

즉, FrontController == Dispatcher (구현에서는 대부분 합쳐져 있음)

---

구조적: 역할 분리할 수 있음

디자인 패턴 설명에서 분기 역할을 따로 설명하는 이유는 다음과 같음

• 유지보수성과 관심사 분리:
  • 공통 처리 (인증, 로깅 등) = Front Controller
  • 요청 분기 로직 (URI 매핑 등) = Dispatcher 혹은 HandlerMapping
• 유연한 확장성: Dispatcher 로직만 수정하여 다른 라우팅 방식 도입 (ex: REST → GraphQL)

---

요약

구분	설명
현실적인 구현	대부분 Front Controller가 Dispatcher 역할까지 함
개념적인 분리	요청 수신, 공통 처리 ↔ 요청 분기, 매핑 등 역할을 나눌 수 있음
이유	코드 구조를 명확히 하고, 유지보수성과 확장성을 높이기 위해서

---