---

MVC 패턴 2강

1. MVC 패턴의 문제점

• MVC 패턴 적용 후 View는 데이터를 Model에서 참조하여 화면을 그리는 역할만 수행
• 하지만 Controller는 여전히 여러 문제점을 포함

MVC 패턴 적용 구조

• Controller와 View가 분리되었지만, 중복 코드와 경로 지정의 불편함이 존재

MVC 패턴의 문제점

1. dispatcher.forward(request, response) → View로 이동하는 forward가 항상 중복 호출됨
2. String path= "/WEB-INF/views/new-form.jsp" → View의 경로를 하드코딩하여 유지보수가 어려움
   • JSP 파일 이름이 변경되면, 해당 코드도 변경 필요
   • JSP 이외의 확장자로 변경 시 전체 코드 수정 필요
3. HttpServletResponse 객체 사용 빈도 감소 → JSP에서 해결하기 때문 (테스트 코드 작성 어려움)
4. 공통 기능(예: 로그 출력, 인증, 인가)이 많아질수록 Controller의 책임 증가

☞ 이러한 문제를 해결하기 위해 공통 기능을 별도로 처리할 방법이 필요

---

2. 프론트 컨트롤러 패턴

• 모든 요청을 하나의 Servlet(프론트 컨트롤러)이 받아 공통 기능을 처리하는 패턴
• 이후, 요청을 처리할 컨트롤러를 찾아 호출 (Controller Mapping)

프론트 컨트롤러 패턴 구조

1. 모든 요청을 프론트 컨트롤러가 받음
2. 공통 기능(로그, 인증 등) 처리
3. 적절한 Controller를 찾아 호출
4. Controller는 HttpServlet을 상속받지 않아도 됨

프론트 컨트롤러의 문제점

• 프론트 컨트롤러를 사용하면 모든 컨트롤러가 동일한 형태의 응답을 반환해야 함
• 하지만 각 컨트롤러는 다른 응답을 처리해야 하는 경우가 많음
• 이를 해결하기 위해 어댑터 패턴(Adapter Pattern)이 등장

---

3. 어댑터 패턴

• 컨트롤러(Handler)를 유연하게 만들기 위해 어댑터 패턴 도입
• 서로 다른 인터페이스를 가진 컨트롤러를 연결하는 역할 수행

어댑터 패턴 구조

1. Controller(Handler)가 비즈니스 로직을 처리하고 결과 반환
2. 어댑터가 프론트 컨트롤러와 Controller 사이를 연결
3. 프론트 컨트롤러는 공통 처리 로직을 수행한 후 적절한 컨트롤러 호출

어댑터 패턴의 장점

• 프론트 컨트롤러, 어댑터, 컨트롤러가 각자의 역할만 수행 → 책임 분리
• 새로운 컨트롤러가 추가되어도 어댑터만 추가하면 됨 → 확장성 증가

---

4. MVC 패턴의 발전 과정 요약

1. Servlet 사용 → 비즈니스 로직과 View 코드가 함께 존재 → 유지보수 어려움
2. JSP 사용 → View는 분리되었지만, 여전히 비즈니스 로직 포함
3. MVC 패턴 도입 → 공통 로직 처리 중복 발생
4. 프론트 컨트롤러 패턴 적용 → 공통 로직을 한곳에서 처리
5. 어댑터 패턴 도입 → 서로 다른 컨트롤러를 유연하게 연결 가능
6. Spring MVC → 프론트 컨트롤러 패턴 + 어댑터 패턴 적용된 웹 애플리케이션 개발 방식

☞ Spring MVC는 MVC 패턴에 프론트 컨트롤러 패턴과 어댑터 패턴을 적용하여 문제점을 해결