취업 준비, 스프링 부트 강의

강의

스프링 MVC 프레임 워크 만들기

v1 - 프론트 컨트롤러

v2 - view 분리 (View.render)

v3 - 서블릿 종속성 제거 (ModelAndView) , 뷰 이름 중복 제거 (viewResolver)

v4 - 단순, 실용적 (Model), 뷰의 논리 이름 반환, 모델이 파라미터로 들어오기 때문에 직접 생성하지 않아도 됨

v5 - 어댑터 패턴 적용하여 프론트 컨트롤러가 여러가지 컨트롤러 처리 가능 (HandlerAdapter, Handler)

 

서블릿 종속성을 제거하기 위해 model 사용

application.properties ⇒ logging.level.org.apache.coyote.http11=debug

DispatcherServlet = FrontController

 

MVC 프레임 워크 동작 순서

1. 핸들러 조회
2. 핸들러를 처리할 수 있는 핸들러 어댑터 조회
3. hadle(handler)
4. handler 호출
5. ModelAndView 반환
6. viewResolver 호출
7. View 반환
8. render(model) 호출

 

HandlerMapping 의 맵핑 순위

0 = RequestMappingHandlerMapping : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용

1 = BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러를 찾음

 

@RequestMapping

가장 우선순위가 높은 핸들러 매핑과 핸들러 어댑터는 ‘RequestMappingHandlerMapping’, ‘RequestMappingHandlerAdapter’ 이다.

위의 핸들러와 매핑 핸들러 어댑터의 이름은 @RequestMapping의 앞글자를 따서 만든 이름이다.

 

스프링 부트에 jar 를 사용하면 /resources/static 위치에 index.html 파일을 두면 Welcome 페이지로 처리해준다.

 

로깅 라이브러리

로그 레벨 (아래로 갈수록 레벨이 높아짐)

trace : 모든 로그 보기

debug : 디버그 (trace 제외한 모든 로그 보기) - 개발 서버

info : 비지니스 정보, 운영시스템 정보 (기본) - 운영 서버

warn : 경고

error : 에러

System.out.println 은 레벨과 관련없이 로그에 출력되기 때문에 사용하지 않는것이 좋다.

 

로그 선언

private Logger log = LoggerFactory.getLogger(getClass());

private static final Logger log = LoggerFactory.getLogger(Xxx.class);

@Slf4j (롬복)

 

올바른 로그 사용

log.info(”info debug={}”, name) ⇒ 올바른 사용

log.info(”info debug=” + name) ⇒ 사용하지 않아야함

로그레벨이 info라고 가정했을때 debug 레벨의 로그가 실행되지 않음에도 + 연산자의 사용으로 인해 의미없는 연산이 일어나며, 쓸모없는 리소스를 사용하게 된다.

 

로그 사용시 장점

쓰레드 정보, 클래스 이름 같은 부가 정보를 함께 볼 수 있고, 출력 모양을 조정할 수 있다.

별도의 설정을 해주면 로그를 파일로 남길 수 있다.

성능이 System.out.println 보다 좋음 (내부 버퍼링, 멀티 쓰레드 등)

 

@RestController

반환값으로 뷰를 찾는것이 아니라, HTTP 메세지 바디에 바로 입력 한다.

@ResponseBody와 관련이 있다.

 

@RequestMapping

대부분의 속성을 배열로 제공하므로 다중 설정이 가능하다. {”/hello-basic”, ”/hello-go”}

따로 설정이 없으면 모든 메소드를 허용한다. (get, post, put, head, patch, delete)

 

경로변수

PathVariable(/{변수}) vs QueryParameter(?변수명=변수)

pathVariable 다중으로 사용가능 ⇒ /mapping/users/{userId}/orders/{orderId}

 

consumes (서버 입장에서의 소비) ⇒ request 헤더의 content-Type 지정

produce (서버 입장에서의 생산) ⇒ responses 결과의 타입 지정

 

요청 매핑 예시

회원관리 API

회원 목록 조회: GET (’/users’)

회원 등록 : POST (’/users’)

회원 상세 조회 : GET (’/users/{userId}’)

회원 수정 : PATCH (’/users/{userId}’)

회원 삭제 : DELETE (’/users/{userId}’)

 

요청 파라미터 종류

@RequestHeader MultiValueMap<String, String> ⇒ 헤더의 값을 전체 다 받음

@RequestHeader(”host”) String host ⇒ 헤더의 특정값을 받음

@CookieValue(value = “myCookie”, required = false) String cookie ⇒ 특정 쿠키값을 받는데 없어도 상관없음을 의미

 

@Data

@Getter, @Setter, @RequiredArgsContructor, @ToString, @EqualsAndHashCode 와 동등하다

 

@ModelAttribute가 있으면 다음을 실행한다.

1. 해당 객체를 생성한다.
2. 요청 파라미터의 이름으로 HelloData 객체의 프로퍼티를 찾는다. 그리고 해당 프로퍼티의 setter를 호출해서 파라미터의 값을 입력(바인딩)한다.

 

@ModelAttribute와 @RequestParam 둘다 생략됐을 때 스프링의 규칙

‘String’, ‘int’, ‘Integer’ 등 단순 타입의 경우 = @RequesParam 사용

나머지의 경우 = @ModelAttribute 사용 (argument resolver 로 지정해둔 타입 외)

 

HttpEntity ⇒ @RequestBody, @ResponseBody

@RequestBody 는 생략할 수 없다.