⚠️ MVC 패턴의 한계
- MVC를 도입해 View는 분리되었지만, Controller는 여전히 복잡한 책임을 가짐
📉 Controller의 문제점
1. forward(request, response) 중복 호출
2. View 경로(String path = "/views/...")가 하드 코딩됨
→ 파일 변경 시 전체 수정 필요
3. HttpServletRequest, HttpServletResponse는 테스트도 어렵고 사용성 낮음
4. 공통 기능(로그, 인증 등)이 Controller마다 중복 구현됨
💬 공통 기능 처리
- 모든 컨트롤러에서 공통으로 적용되는 기능을 뜻함
- ex) 로그 출력, 인증, 인가 등
❗ 공통 기능을 메서드로 분리해도 개별 호출 누락과 책임 증가 문제는 여전함
🚪 프론트 컨트롤러 패턴(Front Controller)란?
- 하나의 Servlet이 모든 요청을 받아 공통 기능을 처리한 뒤,
실제 Controller에 요청을 전달하는 구조
🧭 프론트 컨트롤러 패턴 구조
[Client]
↓
[Front Controller]
↓
[각 Controller]🔍 역할
- 모든 요청을 Front Controller에서 수신
- 공통 로직 처리 (인증, 로깅 등)
- 각 Controller로 라우팅
- 개별 Controller는 더 이상
@WebServlet이 필요 없음
❓ 모든 응답 형태를 통일해야 하나?
- 모든 Controller가 동일한 형태의 응답을 반환해야 한다면?
→ 유지보수 어려움, 공통 로직에 응답별 처리 책임까지 전가됨
🔌 어댑터 패턴(Adapter Pattern)이란?
- 다양한 형태의 Controller(Handler)를 유연하게 연결하기 위해 도입
→ 서로 다른 인터페이스 간의 중간 연결고리 역할
🛠️ Adapter 구조
[Front Controller]
↓
[Handler Adapter]
↓
[Controller/Handler]💡 장점
- Front Controller, Adapter, Handler는 역할이 명확히 분리됨
- 새로운 Controller 타입이 추가되어도 공통 로직은 변경되지 않음
→ Adapter만 추가하면 OK
📌 전체 흐름 요약
| 단계 | 설명 |
|---|---|
| 1️⃣ Servlet | 로직 + View 혼합 → 유지 보수 어려움 |
| 2️⃣ JSP | View 분리했지만 로직 포함 → 책임 과다 |
| 3️⃣ MVC | 역할은 분리했지만 공통 로직 중복 |
| 4️⃣ 프론트 컨트롤러 | 공통 입구에서 공통 로직 처리 |
| 5️⃣ 어댑터 패턴 | 다양한 Controller 타입 유연하게 연결 |
| ✅ Spring MVC | 위 구조들이 모두 반영된 고도화된 구조 |
🎯 결론: Spring MVC의 핵심은?
- 프론트 컨트롤러 + 어댑터 패턴 + MVC 패턴
→ 요청 분기, 공통 로직 처리, 다양한 컨트롤러 지원, 유지보수성 향상
