스프링 MVC

MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.

MVC (Model - View - Controller) 디자인 패턴
Server 에서 HTML 을 내려 주는 경우

1. 정적(Static) 웹 페이지

Controller
1. Client 의 요청을 Model 로 받아 처리
  1. 예) 회원가입을 위한 개인 정보들 (id, password, name)
  즉, 여기서 Model은 클라이언트에서 서버로 보내는 정보들이다.
2. Client 에게 View (정적 웹 페이지, HTML) 를 내려줌

2. 동적 웹 페이지

Controller
1. Client 의 요청을 Model 로 받아 처리
2. Template engine 에게 View, Model 전달
  1. View: 동적 HTML 파일
  2. Model: View 에 적용할 정보들 - 즉 여기서 Model은 컨트롤러가 템플릿 엔진에게 보내는 것이다.
3. Template engine
  1. View 에 Model 을 적용 → 동적 웹페이지 생성
    1. 예) 로그인 성공 시, "로그인된 사용자의 id" 를 페이지에 추가
    2. Template engine 종류: 타임리프 (Thymeleaf), Groovy, FreeMarker, Jade 등 (스프링에서 JSP 이용은 추천하지 않고 있음)
4. Client 에게 View (동적 웹 페이지, HTML) 를 내려줌

Client → DispatcherServlet
1. 가장 앞 단에서 요청을 받아 FrontController 라고도 불림
DispatcherServlet → Controller
- API 를 처리해 줄 Controller 를 찾아 요청을 전달
- Handler mapping 에는 API path 와 Controller 함수가 매칭되어 있음
  - GET /hello/html/dynamic → HomeController 의 helloHtmlFile() 함수
  - GET /user/login → UserController 의 login() 함수
  - GET /user/signup → UserController 의 signup() 함수
  - POST /user/signup → UserController 의 registerUser() 함수
  - 함수 이름을 내 마음대로 설정 가능했던 이유!!
  - Controller 에서 요청하는 Request 의 정보 ('Model') 전달String query(아래 코드 한정)에 전달해 줘라 - 이역할을 DispatcherServlet이 해주고 있었다.
  - 참고로 @RequestParam은 단일 파라미터를 전달 받을 때 사용하는 어노테이션 입니다.
  - @RequestParam 을 통해서 정보가 클라이언트로 왔을 텐데 그 클라이언트 정보를
  - ```
  @Controller
  public class ItemSearchController {
        @GetMapping("/api/search")
    @ResponseBody
    public List<ItemDto> getItems(@RequestParam String query) {
            // ...
    }
  }
```
Controller → DispathcerServlet
1. Controller 가 Client 으로 받은 API 요청을 처리
2. 'Model' 정보와 'View' 정보를 DispatcherServlet 으로 전달@ResponseBody를 하는 경우는 전달이 안된다.
3. Html을 내려주는 경우는 Model정보와 view정보를 넘겨준다.
4. Model하고 View를 거치지 않는 경우도 있다.
DispatcherServlet → Client
1. ViewResolver 통해 View 에 Model 을 적용 (템플릿 엔진이 해준다.)
2. View 를 Client 에게 응답으로 전달

Controller와 http response 메시지 - RestController 가 아니라 Controller 기준

Controller와 http request 메시지 - RestController 가 아니라 Controller 기준

@ModelAttribute 로 선언한 객체에는 @Setter 선언이 필요 ★

dto는 클라이언트에 온 요청들을 가지고 있는데

보통 Entity를 바로 클라이언트에게 보내지 않고

dto로 변환해서 보내주는게 일반적이다.

왜냐하면

db의 내용이 클라이언트에게 보내야 될 내용과 다를 수 있기 때문이다.

그렇기 때문에 클라이언트로 보내는 response dto로 변환해서 보내주는게 일반적이다.

즉, 지금 상태는(강의처럼 response dto를 만들지 않은 상태)는 어떻게 보면 강한 결합인 것이다.

db에 변동이 있으면 그게 클라이언트에까지 영향이 가기 때문이다.

그래서 나중을 생각했을 때 response dto를 따로 만드는게 좋다.

강의에서는 response dto 까지느 만들지 않는다.