---

▪️MVC 패턴 개요▪️

---

📖 Template Engine

💡동적인 웹페이지를 생성하기 위해 사용되는 도구 / 흔히 말하는 UI (SSR에 사용)

📌 등장 배경

• HTML 문서 중 동적으로 변경해야 하는 부분만 자바 코드로 넣을 수 있어 더 편리하다

• 예를 들어 웹페이지가 있을 때
  특정 글을 조회할 때, 변하는 부분만 변하고 나머지 요소들은 고정임
  변해야 하는 곳만!! 코드로 넣어준다

📌 대표적인 템플릿 엔진

• 1️⃣ 타임리프 - 스프링과 연동이 잘되고, 다양한 기능이 많다
• 2️⃣ JSP

---

📖 MVC 패턴 등장 배경

💡서블릿과 jsp만으로 만들면 비지니스 로직과 뷰 렌더링까지 처리하기가 구조가 넘 복잡함 (유지보수 힘듦)
➝ 따라서 mvc (모델 뷰 컨트롤러) 패턴을 사용한다

✔️ Servlet, JSP만 사용시 문제점

Servlet	JSP
화면을 그리는 로직과, 비즈니스 로직이 하나의 Servlet 안에 다 섞여 들어있음	우리가 많이 본 html코드가 자바코드랑 같이 있음 ➝ 서블릿에서 뷰만 분리된것
다 섞임	뷰는 분리되었지만 로직이 섞임

---

📖 MVC 패턴

---

💡하나의 jsp나 servlet으로 처리하던걸 Model , View , Controller 로 분리

• 🌟 비즈니스 로직과 뷰의 완전한 분리!!

✔️ Controller

• HTTP Request를 전달받아 파라미터 검증
• View에 전달할 결과 조회 후 Model에 임시저장
• Layered architecture 구조 이용해 역할이 또 세분화 된다!
  • 1️⃣ Controller Layer ➝ HTTP Request를 전달받아 파라미터 검증
  • 2️⃣ Service Layer ➝ 비즈니스 로직 실행
  • 3️⃣ Repository Layer ➝ 데이터 베이스와 상호작용

✔️ Model

• View에 출력할 데이터를 저장

✔️ View

• Model 객체의 데이터를 이용해 화면을 Rendering

---

📌 MVC 패턴의 문제점

기능별로 서블릿이 계속 필요함..

• 중복 호출
• 뷰의 경로도 계속 입력해줘야한다
• 리퀘스트는 사용하지만 리스폰스를 안씀 ( jsp가 다 처리하기 때문에 )
• *공통 기능이 추가 될 수록 컨트롤러가 처리할 부분이 많아짐
  ➝ 메서드로 만들어서 호출하면 되는거 아닌가요?
  • 이것도 메서드도 중복 호출해야하고 까먹을 수도 있음
  • 메서드 늘어날때마다 컨트롤러 작업범위 커짐

*공통기능?
모든 컨트롤러에서 공통으로 적용되는 기능 (log 출력, 인가 등)

---

📖 프론트 컨트롤러 패턴

💡컨트롤러 호출 전에 공통기능을 하나의 서블릿에서 처리해주는 패턴
➝ 입구가 하나다! 공통기능의 서블릿을 꼬옥 지나가야해

1. 모든 요청을 받고 공통기능을 처리
2. 요청을 처리할 수 있는 컨트롤러를 찾아서 호출한다 ➝ 컨트롤러 맵핑
3. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다
   ( 나머지 애들은 상속이나 webservlet을 안써도 된다 )
   ➝ 응답은 전부 다른 형태로 나올 수 있으니 어댑터 필요

---

📖 어댑터 패턴

💡 다양한 컨트롤러 핸들러를 유연하게 만들기 위해 도입

1. 컨트롤러는 로직 처리 후 그것에 맞는 결과를 반환
2. 반환된 응답을 어댑터가 공통로직과 맞춰 변환한다
3. 프론트 컨트롤러는 공통 로직 수행

• 모두 각자의 역할만 수행한다(책임분리)
• 새로운 핸들러가 추가되어도 어댑터만 추가하면 공통로직에 영향 없음

---

🚀 Spring MVC 패턴 개요

❶ Servlet만 사용 - 비즈니스 로직, View가 분리되지 않음
❷ JSP만 사용 - View는 분리하였으나 로직이 Jsp에 포함
❸ MVC 패턴 사용 - 모델, 뷰, 컨트롤러를 분리하였으나 공통기능임에도 코드를 중복입력해야함
❹ 프론트 컨트롤러 패턴 - 하나의 입구를 만들어 공통기능을 처리하지만 모든 핸들러의 응답을 이것에 맞게 바꿔야함
❺ 어댑터 컨트롤러 패턴 - 핸들러의 응답을 프론트 컨트롤러에 맞게 연결해준다

---

▪️ Spring MVC 패턴▪️

---

📖 Spring MVC 패턴

📌 Front Controller (디스패쳐 서블릿)

• 요청을 받고 알맞는 핸들러, 어댑터를 찾고 반환한다
• 핸들러 목록 , 어댑터 목록을 가지고있다

📌 Handler Adapter

• 내가 처리할 수 있는지? 확인하는 메서드 필요
• 핸들러에게 요청을 지시하는 기능
• 리턴할 때 알맞는 응답으로 변환한다

📌 Handler

• 로직만 처리하면 된다 애들이 다 걸러옴

---

📖 Spring MVC의 주요 Interface

대부분의 기능들이 인터페이스로 만들어져 있기 때문에
DispatcherServlet 코드의 변경없이 기능 변경이나 확장이 가능하다

✔️ 주요 인터페이스 목록

1. HandlerMapping
2. HandlerAdapter
3. ViewResolver
4. View

---

📖 Controller Interface

• 💡인터페이스를 임플리먼트하여 원하는 핸들러를 만들 수 있다
• Annotation 기반의 Controller와는 상관없다

📌@Component

• Spring Bean으로 등록하기 위한 기본 어노테이션
• Spring이 실행될 때, @Component가 붙은 클래스를 찾아서 객체(인스턴스)로 만들고 컨테이너에 등록한다.

@Component = "너 이거 빈으로 등록해!"
@Service, @Repository, @Controller 등 = "이거 빈인데, 역할은 이거야!"

✔️ Spring Bean

• 컨테이너가 관리하는 객체, 즉 인스턴스 !
• Spring은 내부적으로 @Component 계열의 클래스들을 객체화 시키고
  Spring Bean으로 등록해둔다
• 특정 경로로 요청이 들어오면, 해당 경로와 바인딩 된 Spring Bean을 찾아서
  그 Spring Bean에 매핑된 Controller를 찾아 실행해준다.

📌 Handler Mapping, Handler Adapter의 우선 순위

스프링에서 사용자가 /class/1 같은 요청을 보내면,
중앙에서 모든 요청을 받는 DispatcherServlet이 이걸 받아.

근데 DispatcherServlet 혼자선 이렇게 생각함

"이 URL은 누구한테 맡기지...? 누구 메서드 실행해야 하지...?"

HandlerMapping URL을 기반으로 어떤 Bean의 어떤 메서드를 실행할지 찾음
HandlerAdapter 찾은 Bean을 실제로 어떻게 실행할지 방법을 제공

우선순위	Handler Mapping	Handler Adapter	의미
1️⃣	RequestMappingHandlerMapping - Annotation 기반 Controller의 @RequestMapping에 사용	RequestMappingHandlerAdapter - Annotation 기반 Controller의 @RequestMapping에 사용	지금 우리가 쓰는 방식 (@RequestMapping, @GetMapping 등)
2️⃣	BeanNameUrlHandlerMapping - Spring Bean Name으로 HandlerMapping	HttpRequestHandlerAdapter - HttpRequestHandler 처리	특정 URL과 Bean 이름을 매핑하거나, HttpRequestHandler 구현체 사용 시
3️⃣	-	SimpleControllerHandlerAdapter - Controller Interface 처리	과거의 Controller 인터페이스 기반 방식

📖 View Resolver