인프런 - 김영한 강사님의 스프링 MVC 1편을 완강하고 정리하는 글입니다.
강의 링크 : 스프링 MVC 1편

완강은 했는데, 복습을 안하면 머리에 남는 게 없다..

Servlet ( 서블릿 )

웹 어플리케이션 서버 요청 응답 구조

(내장 톰캣 서버는 스프링 부트에서 편리하게 자동으로 생성해준다.)

• 웹 브라우저에서 url에 요청을 날린다.
• WAS(웹 어플리케이션 서버)에서 메시지를 기반으로 request 생성. response 도 같이 생성한다.
• 서블릿 컨테이너에서 WAS한테 두 개를 받아서 실행하고, 종료한 뒤 response를 WAS에 전달하면 WAS가 웹 브라우저에 반환하는 구조

클라이언트에서 서버로 데이터를 전달하는 방법

3가지가 있다.

1. 쿼리 파라미터
2. HTML FORM
3. Message Body에 json, text등 데이터를 직접 담아 요청(HTTP API에서 주로 사용)

한 번쯤 API를 개발해봤으면 다 사용해봤을 것.

강의에서는 이 3가지를 순수하게 자바코드를 이용해서 다루는 것부터 배운다. 뒤에 가면 스프링이 이 기능을 엄청나게 편리하게 제공해준다.

응답 메세지

• HTTP 응답 코드
• 헤더
• 바디

이 3가지가 있다. API만들 때 굉장히 중요하게 다루는 요소들이다.

MVC 패턴

이 패턴이 생긴 이유

하나의 서블릿이나 JSP로 모든 로직과 렌더링을 처리하게 되면,

1. 유지 보수가 굉장히 어려워 진다.
2. 비즈니스 로직과 전혀 관계 없는 UI를 건드리게 되더라도 로직을 수정해야 하는 일이 발생할 수 있다.
3. 그리고 병렬적으로 처리가 불가능하다. (프론트 작업이 완료되기 전까지 백엔드가 작업을 못하고, 반대의 경우도 생긴다)

그렇다면 MVC란?

MVC는 Model, View, Controller 의 약자이다. 각 자 하는 기능을 구분해보자.

• Controller : HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한 후, 전달할 결과 데이터를 조회에서 모델에 담는다.
  일반적으로는 컨트롤러의 부담을 줄이기 위해 비즈니스 로직은 Service 라는 계층을 따로 생성하여 담아둔다고 한다.
• Model : 뷰에 출력할 데이터를 담아둔다. 이렇게 되면 뷰는 비즈니스 로직이나 데이터 접근 방식에 대해서 아예 모르더라도 원하는 데이터를 출력할 수 있다.
• View : 모델에 담겨있는 데이터를 이용하여 화면에 나타나는 일을 전담한다. 프론트엔드라고 이해했다.

그림으로 나타내면 이러한 구조를 가진다.

Redirect vs Forward

• Redirect : 실제 클라이언트에 응답이 나갔다가 클라이언트가 다시 요청을 하기 때문에, 클라이언트가 인지할 수 있고, 실제로 url도 변경이 된다.
• Forward : 서버 내부에서 일어나는 호출이기 때문에 클라이언트는 전혀 인지하지 못한다.

순수 MVC 패턴의 단점

1. 중복되는 코드가 많다.
2. 사용하지 않는 코드도 작성할 때가 있다.
3. 공통으로 처리해야 하는 부분이 많다.

프로젝트의 규모가 커질 수록 문제가 될 수 있는 부분들이다.
따라서 이러한 문제를 해결하기 위해 Front Controller 패턴을 도입하게 되고, 스프링 MVC의 핵심 기능도 바로 이 컨트롤러이다.

스프링 MVC

스프링 MVC 구조

1. 핸들러 매핑을 통해 요청 URL에 적합한 컨트롤러를 찾는다.
2. 핸들러를 처리할 수 있는 핸들러 어댑터를 찾는다.
3. 찾았으면 처리할 데이터를 핸들러 어댑터를 실행하여 실제 컨트롤러(핸들러)에 전달한다.
4. 컨트롤러가 데이터를 처리하여 반환하면 어댑터가 ModelAndView 로 반환한다.
5. 그리고 View는 ViewResolver에 날려주면
6. ViewResolver에서 뷰의 논리 이름을 물리 이름으로 바꾸는 등 렌더링 역할을 담당하는 뷰 객체를 찾아 반환해주고
7. View에 Model이 렌더링 된다.

(혹시 오류가 있으면 지적 환영합니다..)

이처럼 공통 역할은 앞단에서 처리해주고, 나머지 중요한 역할별로 분할해서 처리하는 것이다.

스프링 MVC 기능들 정리

컨트롤러

• @Controller : 자동으로 스프링 빈으로 등록되며, 스프링 MVC에서 어노테이션 기반 컨트롤러로 인식하게 해준다.
• @RestController : 추가로 @ResponseBody 를 붙인 것이라고 생각하면 된다. 요즘 자주 사용되는 REST API를 위한 어노테이션.
  반환 값으로 뷰를 찾는 것이 아니라 HTTP Message Body에 바로 입력한다.

매핑은 다 알고 있으니까 생략한다.

파라미터

• @RequestParam : url에 파라미터가 붙어서 오는 경우(?username=me&age=17) 파라미터를 처리할 수 있게 해준다.
• 파라미터가 한 개인 것이 확실하지 않다면 MultiValueMap 을 사용하도록 하자. 복수 파라미터를 받게 해준다.
• @ModelAttribute : 요청 파라미터를 받아서 객체에 값을 넣는 과정을 완벽히 생략해준다. 말도 안되게 편한 기능이다.
• 사실 다 생략 가능하고 객체만 파라미터로 넣어 놓아도 @ModelAttribute를 적용한 것처럼 취급이 된다.
• 이거 관해서는 몇 가지 규칙이 있는데, 사용하면서 익히면 된다. 오류 나는 것도 직접 경험해보는게 좋을 것 같다.

로그

• Lombok의 @Slf4j를 사용하면 로그백 객체 생성 안해도 편하게 사용 가능하다.
• 로그 레벨이 존재한다. TRACE > DEBUG > INFO > WARN > ERROR
• 개발 서버는 디버그 , 운영 서버는 INFO 로 레벨 설정해두는 것이 좋다. 하위 레벨 로그는 다 출력한다.
• 로그는 반드시 사용하자.

이 정도면 기능 정리는 충분히 한 것 같다.
다음 강의도 열심히 들어야지!