MVC 개요

• 화면을 처리하는 부분
• 비지니스 로직을 구성하는 로직

이 두개의 기능이 하나의 처리에서 수행된다.

• 어디를 손보든 계속 둘다 관리해줘야 한다.
• 코드의 길이가 커버할 수 없을 정도로 길어진다.

변경의 라이프 사이클이 다르면 분리해야한다

화면의 글자 크기 수정은 비지니스 로직이 관계가 없는 경우가 대부분이다.

Controller

• HTTP 요청을 받아 파라미터를 검증하고 비지니스 로직을 수행한다.
  그 후 뷰에 전달할 데이터를 조회해 모델에 담는다

Service

• 컨트롤러에서 모든 로직을 수행하면 너무 큰 부담을 지니기 떄문에 데이터 접근 , 로직을 수행하는 역할
• 컨트롤러는 컨트롤에 집중하는게 좋다.

Model

• 뷰에 출력할 데이터를 담아둔다 . 뷰가 필요한 데이터를 모두 담아 전달해주기 떄문에 뷰는 화면을 랜더링하는 일만 하면 된대 (requeset.setAttriburt / model.addAttribute)

View

• 모델에 담겨있는 데이터를 활용해 화면을 랜더링하는데 집중한다.

중복되고 이미 아는 부분이 많아 추후 Pdf로 정리 예정

MVC 패턴의 한계

• View 로 이동하는 코드가 항상 중복 호출해야한다.
• ViewPath의 중복 ( 만약 JSP가 아닌 탬플릿으로 변경하게 될 경우 문제 .jsp)
• 공통 처리가 어렵다.
  • 로그 출력 같이 모두가 필요한 기능
  • 메서드로 분리해도 매번 메서드 호출이 필요하다.
  • Servlet이 해석되기전 전처리 기능이 필요 ( 수문장…? )
  • 해결 :: Front Controller

---

프론트 컨트롤러

• 여러 종류의 요청을 하나의 컨트롤러가 받아 목적에 맞는 컨트롤러로 전달한다.
  

특징

• 프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받는다.
• 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출한다.
• 입구는 하나가 된다.
• 공통처리가 가능하다 ( Filter와 다른 의미 )
• 프론트 컨트롤러를 제외하고는 서블릿을 사용하지 않아도 된다.

웹 MVC의 핵심은 프론트 컨트롤러
DispatcherServlet이 대표적인 FrontController 패턴

• 컨트롤러 입장에서는 HttpServletRequest / Respnose가 필요한가?

• 요청 파라미터는 DTO,VO,Map으로 다루게 되면 더 편해지게 된다

• request에 값을 담아 Model로 활용하지 않고 임의의 Model을 객체로 다뤄 반환하면 된다.

• ⇒ 코드 구현이 쉬워지고 , 테스트 구축이 쉬워진다.

• v1: 프론트 컨트롤러를 도입기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입

• v2: View 분류단순 반복 되는 뷰 로직 분리

• v3: Model 추가

  • 서블릿 종속성 제거
  • 뷰 이름 중복 제거

• v4: 단순하고 실용적인 컨트롤러

  • v3와 거의 비슷
  • 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공

• v5: 유연한 컨트롤러

  • 어댑터 도입
    • 핸들러 매핑에서 처리를 할 수 있는 어댑터.
  • 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계

@ 어노테이션을 이용해 컨트롤러를 지속적으로 발전 시켜 나갈 수 있다.

@RequestMapping 이라는 핸들러 매핑을 스프링에서 볼 수 있다.

> 프레임워크나 공통 기능은 수고로워야지 개발자가 편해진다.
> 

---

# 스프링 MVC 전체 구조

DispathcerServlet

Spring에서 구현된 FrontController

부모 클래스에서 HttpServlet을 상속받아 사용한다.

스프링은 DIspatcherServlet를 Servlet으로 등록하며 내장 톰캣을 시작한다.

• 모든 경로에 대해 urlPatterns=”/”에 대해 매핑한다.

• 자세한 경로는 우선순위가 더 높다 , 그래서 기존에 등록한 서블릿도 함께 동작한다.

• 서블릿이 호출되면 HttpServlet이 제공하는 service()가 호출된다.

• 스프링 MVC는 DispatcherServlet의 부모인 FrameworkServlet에서 Service() 오버라이드 해두었다.

• FrameworkServlet.service()를 시작으로 순차적으로 수행되어 DispatcherServlet.doDispatch()가 호출 된다.

DispatcherServlet.doDispatch();

• .getHandller()로 핸들러를 찾는다.
• 없을 경우 404를 매핑해 반환한다 ( noHandlerFound )

1. 핸들러 조회
2. 핸들러 어댑터 조회
3. 핸들러 어댑터 실행
4. 핸들러 어댑터를 통해서 핸들러 실행
5. ModelAndView를 반환한다.
6. rander 호출해 뷰의 이름을 가져온다.
   1. String viewName = mv.getViewName();
7. 뷰 리졸버를 호출해 뷰를 찾는다.
8. View 반환
9. 찾은 뷰를 랜더링한다.

❕ 스프링 MVC의 큰 강점은 DispathcerServlet 코드의 변경 없이 원하는 기능을 변경하거나 확장할 수 있다는 점이다. 대부분 확장 가능할 수 있도록 인터페이스로 제공하기 때문.

인터페이스들만 구현해 DIspatcherServlet에 등록하면 나만의 컨트롤러를 커스텀할 수도 있다.

• 사실상 불가능 …너무 빡세기 때문에