MVC 패턴의 한계점

MVC 패턴은 애플리케이션 개발 구조로서 유용하나, 다음과 같은 문제점을 내포한다.

• View 이동 시 중복 호출: View로의 forward 로직이 관련 클래스에서 반복적으로 호출된다.
• View 경로 하드코딩: View 경로 (String path= “/WEB-INF/views/new-form.jsp”)의 직접 명시로 인한 중복 및 변경 의존성 발생.
• View 확장성 제약: JSP 외 템플릿 엔진 변경 시 전반적인 수정 불가피.
• HttpServletResponse 객체 활용 저조: View (JSP) 단에서 응답 처리 집중으로 HttpServletResponse 객체 직접 사용 빈도 낮음. 이는 테스트 코드 작성의 어려움을 야기한다.
• Controller 책임 증가: 공통 기능 추가에 따른 Controller 처리 부담 증가.

프론트 컨트롤러 패턴

프론트 컨트롤러 패턴은 Servlet 호출 전 공통 기능을 단일 Servlet에서 처리하는 방식이다. 모든 클라이언트 요청은 단일 프론트 컨트롤러(Servlet)로 집중된다.

프론트 컨트롤러의 역할

• 모든 클라이언트 요청을 단일 프론트 컨트롤러가 수신한다.
• 공통 기능을 처리한다.
• 요청 처리 가능 Controller를 탐색하여 호출한다 (Controller Mapping).
• 프론트 컨트롤러 외 Controller는 Servlet 직접 사용 불필요. HttpServlet 상속 또는 @WebServlet 어노테이션 사용은 필수가 아니다.

프론트 컨트롤러의 의문점

프론트 컨트롤러 적용 시, 모든 Controller가 동일 형태 응답을 생성해야 하는가에 대한 의문 제기 가능. 각 Controller의 비즈니스 로직 및 응답 결과는 상이하며, 획일적 응답 방식 강제는 애플리케이션 확장성 및 유지보수성 저하를 초래할 수 있다. 공통 로직에서 응답별 세부 처리 가능하나, 이는 공통 부분의 책임 과중을 유발하며, Controller 반환 결과 변경 시 공통 처리 부분 수정 또한 불가피하다.

어댑터 패턴

다양한 Controller (Handler)의 유연한 처리를 위해 어댑터 패턴 도입. Controller는 동일 인터페이스를 구현하고, 해당 인터페이스와 공통 로직 간 어댑터를 두어 연결 유연성을 확보한다. 어댑터 패턴은 상이한 인터페이스를 갖는 두 클래스를 호환 가능하도록 연결하는 패턴이다.

어댑터 패턴 구조

• 컨트롤러 (Handler): 비즈니스 로직 처리 및 적절 결과 반환.
• 어댑터: 공통 로직과 컨트롤러 (Handler)의 자연스러운 연동 매개.
• 프론트 컨트롤러: 공통 처리 로직 수행.

어댑터 패턴의 장점

• 프론트 컨트롤러, 어댑터, 핸들러 각자의 역할 수행 (책임 분리).
• 신규 컨트롤러 (Handler) 추가 시, 해당 컨트롤러 및 어댑터 추가만으로 공통 로직 변경 없이 확장 가능.

요약

• Servlet 사용: 비즈니스 로직과 View 코드 혼재 문제 발생.
• JSP 사용: View 코드 분리되었으나, 비즈니스 로직이 JSP에 포함될 가능성 존재.
• MVC 패턴 사용: 공통 로직 처리 부분의 코드 중복 발생.
• 프론트 컨트롤러 패턴 사용: 공통 로직 단일 진입점에서 처리하나, 각 핸들러 응답을 프론트 컨트롤러 형식에 맞춰 변환해야 하는 문제 발생.
• Spring MVC 사용: 프론트 컨트롤러 패턴과 어댑터 패턴을 모두 적용한 형태로서, 현재 사용되는 Spring 기반 웹 애플리케이션 개발 방식에 적용됨. Spring은 MVC 패턴에 프론트 컨트롤러 패턴 및 어댑터 패턴을 통합 제공한다.